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1.  Reference:  Memorandum,  DAMO-AFV/-M,  Subject:  Change  One.  AFV 
Computer  Resource  Management  Plan  (CRMP) ,  Volume  XV,  date:  23  Feb  88, 
(cover  st-ieet) 


2 .  instructions: 


a.  A1 !  change  one  page  replacements  are  dated  28  Jan  88.  Make 
the  fi'i  lowing  page  replacements: 


Remove ,  1  Sep  8 7 

Executive  Summary 
Chapter  1 
Chapter  3 
l.ible  of  Contents 


Insert.  Cl  28  Jan  88 
(pages  attached) 

Executive  Summary. 

Chapter  1 . 

Chapter  3. 

Table  of  Contents. 


ink  changes: 

Change  to 


t) .  Make  the  fol  lowing  manual 
Change  from 
' CRMP" 

Computer  Resource 
Management  Plan  (CRMP)" 


"ACRMP"  in  al I  chapters. 

"Automation  and  Communication 
Resource  Management  Plan 
(ACRMP) " . 


Chapter  two  title. 

Requirements  Analysis"  "Requirements  Definition  and 

Analysis"  in  all  chapters. 

3.  Summary  of  changes: 

a,  rtie  AFV  Phase  I  CRMP  has  been  changed  to  the  Automation  and 
Corrmu  n  I  r  a  t  I  o  n  Resource  Management  Plan  (ACRMP)  to  reflect  the 
necess  ir  y  integration  of  computer  and  communication  systems  to 
suppoi  t  a  currmand  ,  control,  corrmu  n  ications  and  intelligence  (C3I) 

ar  c  h  I  t  i.’c  f  u  r  6  . 


b.  Chapter  one.  General  serves  as  the  introduction  to  AFV 
au  t  oma  t  I  o  n  and  corrmu  n  i  ca  t  I  on  ( AC  )  system  resource  managemen  t  .  It  has 
change-,  to  reflect  Department  of  Defense  standard  events  and 
mi lestones  regarding  AC  deve I opmen t . 
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3.  Summary  of  changes  (continued): 


c.  The  ACRMP  will  continue  to  receive  periodic  updates  throughout 
the  AFV  life  cycle.  The  preliminary  ACRMP  will  transition  into  its 
final  form  after  the  Concept  Exploration  Phase  and  before  the 
conclusion  of  the  Demonstr at i on  Validation  Phase,  Milestone  II. 


d.  The  revised  Chapter  3,  Program  Management,  refines  command 
responsibilities.  Its'  goal  is  to  identify  AFV  participating 
commands.  Projects  under  program  executive  or  program  management 
organizations  have  been  listed  in  tabular  form  in  anticipation  of  a 
future  increasing  role  in  AFV  development. 

4.  As  a  minimum  review  concept  exploration  phase  goals  as  identified 
in  chapter  one  and  command  responsibilities  in  chapter  three 
Provide  recommended  distribution  changes  and  document  changes  or 
refinements  to  the  point  of  contact  listed  below. 

5.  Projected  future  changes: 

A.  Chapter  updates  to  reflect  revised  milestones. 

B.  Re f i nements I  to  ensure  adequate  management  of  evolving 
itechno  I  og  i  ca  I  areas)  such  as,  communications,  artificial 
intelligence,  and  robotics. 

C.  Further  changes  to  ensure  consistency  with  change  one. 

D.  Others,  as  recommended  by  AMC  and  TRADOC . 

6.  Post  cover  letter  and  this  instruction  change  sheet  prior  to  the 
ACRMP  index.  Due  to  personnel  changes  and  rapidly  evolving  guidance, 
retain  removed  pages  until  the  conclusion  of  the  AFV  Concept 
Exploration  phase  and  Milestone  I  then  destroy. 

6.  Point  of  contact  is  Major  Robert  D.  Buckstad,  Av  927-1465/6C  or 
(804)  878-xxxx. 
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EXECUTIVE  SUMMARY 
ARMORED  FAMILY  OF  VEHICLES  (AFV) 
PRELIMINARY  AUTOMATION  AND  COMMUNICATIONS 
RESOURCE  MANAGEMENT  PLAN  (ACRMP) 
VOLUME  XV 


This  Automation  and  Coinnun i cat  ions  Resource  Management  Plan  (ACRMP), 
Volume  XV  identifies  organizational  relationships  and  responsibilities 
required  for  the  requirements  definition,  acquisition,  test  and 
evaluation,  deployment,  and  post  deployment  support  of  the  coinnun I  cat  ion 
and  computer  resources  for  the  Armored  Family  of  Vehicle  (AFV).  It  also 
specifies  development,  acquisition,  and  maintenance  concepts  and  policies 
pertaining  to  computer  resources  to  be  used  In  the  AFV.  The  ACRMP 
provides  for  the  management  of  the  Integration  of  a  large  number  of 
hardware  and  software  component  subsystems  into  the  AFV.  Key  to  this 
approach  are  coordinated  resource  management  techniques,  standerd  and 
common  hardware  and  software  components,  low  to  medium  risk  components, 
and  specialized  development  and  maintenance  environments  whose  primary 
purpose  is  to  accomplish  development  and  Integration  of  automation  and 
communication  components  for  the  AFV. 

The  challenge  of  managing  computer  resources  lies  in  the  wide  variety 
of  computer  related  systems  to  be  fielded,  semantic  or  terminology  gaps, 
and  the  proliferation  of  automation  In  general  throughout  the  Army  and  the 
Department  of  Defense.  Tactically,  a  typical  AFV  Subsystem  may  have 
multiple  automated  on-board  systems  such  as  fire  and  weapon  controls, 
internal  and  external  communications,  and  diagnostics.  It  will  also  have 
multiple  external  Interfaces  to  automated  systems  such  as  fire  support, 
air  defense,  and  command  and  control.  Both  Internal  functions  and 
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•xtarnal  intsrfacts  will  ahara  cannon  hardwara  and  aoftwara  componanta 
auch  as  displays,  data  entry  davices,  buaaaa,  and  oparating  ayatama.  Thia 
presents  a  significant  technical  managanent  challenge  aa  the  development 
of  mission  specific  systams  typically  have  not  been  on  connon  hardware  or 
software.  Portability  between  potential  hardware  configurations  is  a 
non-trivlal  task.  Priorities  and  interfaces  eventually  must  ba  defined  to 
the  byte  level  and  eventually  the  bit  level. 


s 


The  AFV  ACRMP  addresses  system  anginaaring,  requirements  validation, 
design  constraints,  risk  managamant,  syatam  support,  configuration 
management,  human  factors,  teat  managamant,  aoftwara  quality  managamant, 
data  and  document  managamant,  logistics  support,  paraonnal ,  ambadded  and 
external  training,  compatibility  and  intaroparabi I Ity,  Independent 
validation,  security,  funding  and  organization  roles,  reaponalbl l i t les. 
and  relationships.  Comprahana i va  combat  and  material  development 
technical  managamant  Is  an  absolute  necaasity.  The  ACRMP  is  formatted  m 
seven  Chapters  and  appendices  to  support  AFV  objectives.  A  brief  overview 
of  the  contents  of  each  Chapter  Is  provided  here; 


Chapter  1 


General .  Chapter  one  describes  general  guidance  and 


serves  as  an  Introduction  to  AFV  automational  communication 
resource  development.  It  outlines  the  purpose,  scope,  and 
background  of  AFV.  It  also  Includes  an  overview  of  the  Automation 
and  Communications  Resource  Working  Group  (ACRWG)  that  will 
support  the  preparation  and  maintenance  of  the  AFV  ACRMP.  A 
summary  of  overall  AFV  system  requirements  are  Included  and  will 
be  updated  in  planned  revisions  of  the  ACRMP. 


b.  Chapter  2 


Requirements  Definition  and  Analysis .  The 


Requirements  Definition  and  Analysis  Chapter  summarizes  the  AFV 
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requirement  for  automation  and  communications  resources  based  on 
the  Brigade  and  higher  Comnand,  Control,  Communications  & 
Intelligence  (C3I),  Battalion  and  Below  C3I  and  the  Vehicle 
Control  and  Operating  system,  and  the  responsibilities  and 
methodologies  for  accomplishing  requirements  definition  and 
va I  idat i on . 

Chapter  3  -  Program  Management.  The  Program  Management  Chapter 
identifies  the  organizations  and  their  responsibilities  in 
relation  to  AFV  computer  resources  development,  and  describes  the 
management  philosophy  that  will  be  used  throughout  the  life  cycle 
of  the  AFV  program. 

Chapter  4  -  Acquisition  Management.  The  Acquisition  Management 
Chapter  identifies  the  key  resource  aspects  of  the  acquisition 
plan  for  the  system  and  describes  the  acquisition  strategy  that 
will  be  followed  for  procuring  the  computer  resources  to  Include 
the  development  of  the  Life  Cycle  Software  Engineering  Center 
(LCSEC).  Its  purpose  is  to  supplement  the  AFV  Integrated  Logistic 
Suppor  t  Plan  (1 LSP) . 

Chapter  5  -  Development  Management.  The  Development  Management 
Chapter  describes  the  technical  engineering  approach  and  design 
concepts  that  will  be  followed  during  the  development  phase,  and 
identifies  the  resources,  costs,  and  schedules  associated  with  the 
development  of  the  Individual  communication  or  computer  resource 
I  tern  Technical  control,  testing,  quality  assurance, 
configuration  management,  security,  documentation,  progranmer  and 
developer  environments,  and  training  concepts  are  established. 
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f.  Chapter  6  -  Test  and  Evaluation.  The  Teat  and  Evaluation  Chapter 

identiflea  the  teating  requ Irementa,  reapona I b 1 1  I ty  concepts, 
schedule,  and  resources  needed  to  teat  the  automation  and 
corrvnun Icat  Ion  resource  Items.  Its  purpose  la  to  supplement  the 
AFV  Test  and  Evaluation  Master  Plan  (TEMP). 

g.  Chapter  7  -  Plan  for  Support.  The  Plan  for  Support  Chapter 

identifies  resources  needed  to  support  the  operation,  maintenance, 
and  configuration  control  of  the  computer  resource  Items. 

h .  Append  Ices : 


Appendix  A  -  Acronyms  and  Abbreviations.  This  appendix  is 
provided  for  clarity.  Generally,  acronyms  are  defined  before 
their  use  in  each  chapter  to  take  raadibllity. 

Appendix  8  -  AFV  Vehicle  System  SuBmary- 

Appendix  C  -  Charter  for  the  AFV  Automation  and  Communications 
Raaourcaa  Morkina  Group  (ACRWG) .  The  primary  purpose  of  the 
ACRWG  is  to: 


o  Assist  the  Director,  AFV  Task  Force  (AFVTF)  in 

initiating  early  tasks  and  activities  that  are 
prcraqu I  a  I  tea  to  development  and  test  functions  (such 
as  configuration  management  level  testing  etc.). 

o  To  monitor  the  computer  resources  of  the  AFV  throughout 

the  life  cycle  of  the  AFV  project 

To  ensure  that  the  system  requires  minimum  computer 
resources,  and  y i e I ds  max imum  performance  reliability, 
availability,  maintainability,  and  safety  to  satisfy 


'y 


0 
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the  connmon  needs  of  the  operational  user,  and  the  life 
eye  I e  suppor  ter  . 

o  To  maintain  and  update  the  ACRMP  for  the  AFV. 

0  To  assist  in  ensuring  that  the  ACRMP  Is  in  compliance 

with  all  current  pertinent  policy,  procedures,  plans, 
and  standards  established  for  automation  and 
communication  resources. 

Appendix  D  -  AFV  Task  Force  Technology  Points  of  Contact. 

Appendix  E  -  AFV  Requirement  and  Planning  Documents. 

Appendix  F  -  Management  Checicl ist(s) .  Checklists  included  are 
materiel  development  milestones,  system  design  review, 
specification  review,  design  review,  and  Milestone  I/ll. 

Appendix  G  -  AFV  Integrated  C3.  Presents  AFV  skeleton 
requirements  for  integrated  C3. 

Appendix  H  -  Activities  for  Life  Cycle  Software  Engineering 
Center (s)  (LCSEC)  Support.  Describes  actions  to  ensure 

automation  suppor tab i I i ty . 

Appendix  1  -  Software  Development  Reviews.  Provides  a  list  of 
software  development  reviews 

Appendix  J  -  AFV  Automation  and  Communication  Milestones 
Provides  milestones  related  to  development  of  automation  and 
cofmunc  I  at  I  on  resources. 
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CHAPTER  1  -  GENERAL 


'.1  I NTRODUCT I  ON  -  This  preliminary  Automation  and  Communication  Resource 
Management  Plan  (ACRMP)  Identifies  organizational  relationships,  policies, 
and  responsibilities  related  to  the  requirements  definition,  development, 
acquisition,  test  and  evaluation,  deployment,  maintenance  and  post 
deployment  support  of  the  automation  and  communication  resources  for  the 
Armored  Family  of  Vehicles  (AFV).  Automation  and  communication  resources 
encompass  computer  equipment  and  peripherals,  specification,  programs, 
data,  netMorks,  associated  documentation,  governmental  contractual 
services,  personnel,  communication  equipment,  and  supplies.  The  ACRMP  is 
formatted  into  seven  chapters  In  support  of  DARCOM-R-70- 1 6 ,  Management  of 
Computer  Resources  and  Battlefield  Automated  Systems  and  DOD  Directive 
6000.29,  Management  of  Computer  Resources  In  Major  Defense  Systems. 

1.2  PURPOSE  -  The  Armored  Family  of  Vehicles  ACRMP  is  provided  to  ensure 
that  the  AFV  automation  and  communication  resource  requirements  are 
defined  and  planned  for,  developed,  tested,  acquired,  fielded,  and 
supported  In  a  cost  effective  and  timely  manner.  It  Is  Intended  to 
complement  the  AFV  Integrated  Logistics  Support,  Test  and  Evaluation 
Master,  Manprint  and  Training  Plans.  This  document  is  intended  to 
identify  important  acquisition  and  life  cycle  planning  requirements  and  to 
establish  specific  guidelines  to  ensure  that  those  requirements  are 
adequately  considered  in  the  military  development  and  acquisition  planning 
process  The  preliminary  ACRMP  will  transition  to  Its  final  form  at  the 
conclusion  of  the  Demonstration  Validation  Phase,  Milestone  II,  and 
continue  to  receive  periodic  updates  throughout  the  AFV  cycle. 

I  I  BACKGROUND  -  The  United  States  Army  has  initiated  a  new  program  to 
meei  Army  ground  combat  requ i r en-ents  of  the  future.  The  AFV  Is  intended 
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to  correct  major  def Ic lenc lea  Identified  In  the  Battlefield  Development 
Plan  (BDP)  and  will  provide  a  modern  replacement  for  the  current  Armored 
Fleet.  The  AFV  is  planned  to  provide  enhanced  combat  capability, 
battlefield  synchronization,  Improved  f Ightabl I  I ty ,  a  corrmon  training 
base,  higher  readiness,  lower  operational  and  support  costs  (O&S) ,  require 


1.3.1  History  -  The  AFV  is  a  direct  outgrowth  of  the  1984  Special  Study 
Group  Armor  (SSGA)  Study  In  which  then  LT6  Vuono  established  a  tasking  to 
investigate  the  ancillary  effects  of  Its  efforts  on  the  future  family  of 
vehicles  In  the  SSGA  report,  the  quantitative  and  qualitative 
superiority  of  threat  forces  were  enumerated  along  with  the  need  to 
improve  the  U.S.  capabilities  to  get  ahead  and  stay  ahead  of  this  threat. 
As  a  result,  the  first  AFV  umbrella  Operational  and  Organizational  (O&O) 
plan  was  Initiated  In  January  1986.  The  charter  for  the  Armored  Family  of 
Vehicles  Task  Force  (AFVTF)  was  approved  on  6  October  1986  and  became 
fully  operational  In  June  1986.  The  office  of  the  Secretary  of  Defense 
approved  the  Justification  for  Major  System  New  start  (JMSNS)  in  August  86 
and  the  O&O  Plan  was  approved  In  June  87.  As  one  of  only  five  new  start 
systems  approved,  the  AFV  concept  Is  clearly  a  high  priority  program, 
impacting  the  total  Army  (to  Include  active.  National  Guard,  and  Reserve 
components).  Virtually  all  Training  and  Doctrine  Command  (TRADOC) 
proponents  and  Army  Materiel  Command  (AMO  major  subordinate  commands  will 
be  af  f ected 
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'  J  :  F und i nq  -  Funding  to  initiate  AFV  development  was  included  in  the 
FY.SP  and  FY89  Budget  Submission  and  the  FY88-92  Program  Objective 
Wamorandum  (POM).  Throughout  the  Concept  Exploration  Phase,  FY86  through 
the  4th  QTR  89,  the  AFV  Task  Force  will  continue  to  participate  and 
closely  monitor  the  Mission  Area  Material  Plan  (MAMP) ,  Long  Range  Research 
Development  Acquisition  Plan  (LRRDAP)  and  POM  processes  to  assure  AFV  Is 
adequately  funded  and  duplication  Is  reduced  or  eliminated  and  priorities 
are  fcciised. 


AUG  ’86  FY89  FY92  FY96 
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1 .4  PROGRAM  SUMMARY 

1.4.1  Acquisition  Guidance  -  The  AFV  Charter,  6  October  1985,  included 
the  edict  to  have  hardware  on  the  ground  by  FY9B.  This  guidance  was 
revised  by  the  August  1987  RRC  and  the  AFV  Task  Force  Charter.  Hardware 
fielding  Is  planned  for  FY98. 

1.4.2  Concept  Exploration  Phase  (FY88-89)  -  During  the  Concept 
Exploration  phase  initial  planning  should  be  directed  toward  refining 
proposed  solutions  or  developing  alternative  concepts  to  satisfy  a 
required  operational  capability.  Computer  and  communication  resources 
lifecycle  planning  during  this  phase  will  ensure  that  development  and 
support  of  automation  and  communication  resources  are  adequately 
considered . 

1.4. 2.1  Engineering  Studies,  Analysis  and  Plans  -  Alternative  concepts 
will  normally  be  identified  and  subjected  to  tradeoff  and  optimization 
studies  to  define  a  system  that  meets  mission  requirements  in  the  most 
effective  manner.  The  results  of  these  studies  form  the  basis  for  the 
computer  and  communication  resource  areas  of  the  System  Segment 
Specification.  The  following  types  of  studies  will  be  performed  as 
app I i cab  I e . 

a.  Requirements  Refinement.  Analyze  the  system  requirements 
including  constraints,  to  identify  the  factors  that  drive  requirements  for 
automation  and  communication  resources.  These  factors  may  include  system 
interfaces,  interoperability,  communication  functions,  personnel 
functions,  the  anticipated  level  and  urgency  of  change,  and  requirements 
for  reliability  and  responsive  support.  Document  user  requirements  In  the 
AFV  O&O  or  ROC  as  applicable. 

b.  Operational  Concept  Analysis.  Analyze  the  operational  concept  to 
determine  the  role  of  computer  resources.  Pay  particular  attention  to 
requirements  for  mission  preparation,  operator  interface,  control 
functions,  and  mission  analysis. 
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c.  Tradeoff  and  Optimization  Studies.  Determine  the  effects  of 
system  constraints,  such  as  the  operations  concept,  the  support  concept, 
performance  requirements,  logistics,  availability  and  maturity  of 
technology,  and  limitations  on  cost,  schedule,  and  resources.  Study 
alternative  resource  approaches  for  meeting  operational.  Interoperability, 
and  support  requirements;  system  requirements  for  reliability  and 
maintainability;  alternative  approaches  to  satisfy  requirements  for  system 
security;  and  the  suitability  of  standard  computer  languages,  instruction 
set  architectures,  and  Interfaces. 

d.  Feasibility  Studies.  For  each  candidate  approach,  conduct 
feasibility  studies  to  estimate  cost  and  schedule.  Feasibility  studies 
may  require  the  experimental  development  of  resources.  In  these  cases, 
the  software  development  lifecycle  will  be  tailored  to  accommodate  program 
goals  and  constraints. 

e.  Risk  Analysis.  For  each  alternative  concept,  risk  evaluation 
will  be  conducted.  These  risk  assessments  will  be  Incoporated  in  the 
system-level  risk  management  plan  or  In  the  ACRMP. 

f  Test  Planning.  Start  initial  test  planning  for  computer 
resources  during  this  phase  and  document  these  plans  in  the  system  Test 
and  Evaluation  Master  Plan  (TEMP).  Interface  and  Interoperability  testing 
will  be  included  if  the  system  needs  to  operate  with  other  systems. 

1  4.2.2  Automation  and  Communication  Resources  Working  Group  (ACRWG)  - 
During  this  Concept  Exploration  phase  the  CRWG  will: 


a.  Develop  and  refine  this  ACRMP. 

b.  Develop  alternatives  for  computer  resources  lifecycle  support. 
Evaluate  and  explore  overall  support  concepts,  develop  a  preliminary 
allocation  of  software  support  responsibility,  study  the  potential  for 
organic  and  contractor  support,  and  identify  candidate  organizations  for 
performing  software  support.  Document  conclusions  in  the  ACRMP. 

c.  Identify  any  unique  requirements  for  software  quality.  Identify 
and  prioritize  the  required  software  quality  factors  such  as  interopera¬ 
bility,  portability,  flexibility,  usability,  reusability,  maintainability, 
iiitpgity,  reliability,  correctness,  testability,  and  efficiency.  Define 
the  appropriate  scope  of  Independent  Verification  and  Validation  (IV&V) 
and  develop  a  recommended  approach. 
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d.  Evaluate  the  use  of  standard  equipment,  high  order  languages, 
instruction  set  architectures,  and  interfaces.  Evaluate  the  need  for 
development  of  software  tools  and  recommend  an  approach. 

1.4. 2. 3  Automation  and  Communication  Resource  Planning  -  At  the  end  of 
Concept  Exploration  the  following  products  wi I  I  be  delivered  to  support  a 
milestone  I  decision. 


a.  ACRMP.  Chapter  one.  General  (Introduction)  will  be  completed. 
Chapter  two,  Requirements  will  be  updated  to  reflect  the  AFV  Required 
Operational  Capabilities  (ROC).  Chapter  three.  Program  Management  and 
Chapter  five.  Development  Management  will  be  refined.  Chapter  four. 
Acquisition  Management  and  Chapter  six.  Test  and  Evaluation  will  be 
updated  and  reflect  the  ILSP  and  TEMP.  The  ACRV/G  charter  will  be  staffed 
and  a  copy  will  be  attached  as  an  appendix  to  the  ACRMP.  Draft  appendices 
will  Include  the  Risk  Management  Plan,  Vehicle  Control  and  Operation 
System  (VCOS)  and  Battal Ion  and  Below  Conmand  and  Control  (B2C2) 
Management  Development  Plans. 

b.  Concepts  and  Specifications.  The  preliminary  System  Operational 
Concept  and  System  Segment  Specification  will  be  delivered.  Drafts  of  the 
Interface  and  hardware/software  specifications  will  also  be  produced. 

c.  Plans.  In  addition  to  the  ACRMP  additional  technical  management 
plans  are  required.  Automation  and  communication  configuration 
management,  quality  evaluation  and  development  support  plans  will  be 
produced  in  draft. 

d.  Reviews.  The  ACRWG  will  meet  periodically  and  the  System 
Requirement  Review  will  be  conducted  prior  to  Milestone  I. 

1.4. 2. 4  Object i ves  -  Objectives,  when  achieved,  will  provide  the  basis 
for  the  Milestone  Decision  in  the  4th  Qtr  FY89  to  enter  the  Concept 
Demonstration  Validation  Phase. 


1.4.3  Demonstration  Validation  Phase  (FY90-93)  -  During  the  Demonstration 
Validation  Phase,  the  Army  will  validate  the  choice  of  alternatives  to 
provide  the  basis  for  determining  whether  or  not  to  proceed  Into  Full 
Scale  Development  (FSD) .  Work  efforts  will  be  defined  or  refined  to 
provide  confidence  that  risks  have  been  resolved  or  minimized  and  cost, 
schedule  and  performance  requirements  are  met. 
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1  4.3.1  Engineering  Studies.  Analysis  and  Plans  -  System  engineering 
studies  are  based  on  tbe  concept  of  hierarchy  of  requirements  starting 
with  system- 1  eve  I  requirements  and  ending  with  detailed  engineering 
specifications  and  data.  System  definition  will  proceed  by  refining  each 
level  of  requirements  into  subordinate  requirements  until  the  entire 
system  Is  described  At  each  step,  automation  and  communication  resources 
are  considered  as  an  Integral  part  of  the  system  and  are  subject  to 
tradeoff  and  optimization  studies.  System  engineering  studies  will 
norma  My  i  nc  I  ude  : 

a.  Requirements  Definition:  Technical  requirements  definition  based 
in  operational  requirements  includes  determining  a  preliminary  allocation 
of  requirements  between  hardware  and  software.  Document  the  requirements 
for  each  software  configuration  I  tern  in  a  draft  Software  Requirements 
Specification  (SRS) ,  which  will  be  authenticated  at  the  Software 
Specification  Review  held  (prior  to  or)  early  during  the  PSD  Phase. 

1  b.  Interface  Definition.  The  Automation  and  Conmun icat ions  Resource 

U/orking  Group.  in  conjunction  with  the  (to  be  formulated)  Interface 
Control  IMorlc  Group  or  Board  will  address  system/ subsystem  interface 
rt^qiii  cements  that  may  effect  automation  and  communication  resources. 
Preference  will  be  given  to  military  standard  (MIL-STD)  and  Army  Materiel 
Command  specified  interface  standards.  interface  requirements  will  be 
documented  for  each  Configuration  Item  in  the  Interface  Requirement 
Specification  or  in  (or  referenced)  the  Software/Hardware  Requirements 
Spec  I f i cat i on . 

c.  Technical  Tradeoff  and  Optimization  Studies.  Tradeoff  and 
optimization  studies  will  consider  issues  such  as: 

(1)  Tradeoffs  between  computer  software  and  computer  hardware. 

(2)  Required  processor  architer*  features  such  as  memory 

s  ze.  processor  speed,  and  input  and  capacity,  including  spare 

r  .ipac  I  t  V 

i3)  Use  of  standard  equipment.  Igh  order  languages,  instruction 
sot  ..r  rh  1  tpctures  ,  and  interfaces. 
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(4)  Alternate  approaches  for  meeting  system  security 
requ I rements . 

(5)  Improved  suppor tab  I  I  I ty  versus  improved  performance. 

(6)  High  versus  low  speed  data  conmunicat  Ion. 

(7)  Communication  system  suppor tab  I  I  1 ty . 

(8)  Use  of  existing  Government  resources  or  conmercial  off-the- 
shelf  resources  versus  new  development. 

d.  Feasibility  Studies.  Determine  the  feasibility  of  alternative 
allocations  of  system  requirements  to  computer  resources  and  derive  data 
for  formulating  budgets  and  schedules. 

e.  Risk  Analysis.  One  of  the  most  Important  objectives  of  the 
Demonstration  and  Validation  phase  is  to  identity  development  risk,  so 
that  risk  management  can  be  applied  during  FSD.  Identification  of  the 
major  risks  to  the  development  effort.  Incorporate  plana  to  manage  these 
risks  Into  the  system  level  risk  management  plan  or  In  the  ACRMP. 

f.  Software  Support  Studies.  Conduct  software  support  studies  as 
needed  to  refine  the  system  support  concept  and  allocate  software  support 
requirements.  These  studies  should  also  determine  how  software  which  is 
loaded  In  the  operational  system  will  be  identified,  through  such  methods 
as  self-identification  of  executing  software,  identification  plates 
affixed  to  the  outside  of  the  computer,  and  so  forth. 

g.  Test  Planning.  Establish  quantitative  and  demonstrable 
performance  objectives  and  evaluation  criteria,  reflecting  those  of  the 
overall  system,  for  the  computer  hardware  and  software.  Based  on 
criticality  of  so f twar e- i ntens I ve  system  functions,  determine  the  system/ 
software  test  approach  and  test  tools  to  reduce  risk  to  an  acceptable 
level.  Update  the  Test  and  Evaluation  Master  Plan  (TEMP)  to  reflect  the 
test  objectives  (performance,  functional.  Interface,  interoperability, 
etc.)  and  evaluation  criteria  for  the  computer  resources  In  the  system. 
Include  plans  for  Development  Test  and  Evaluation  (DT&E)  and  Operational 
Test  and  Evaluation  (OT&E)  of  computer  resources. 

h.  Development  of  Prototype  Computer  Resources.  During  the 
Demonstration  and  Validation  phase,  It  will  be  necessary  to  develop 
prototype  system  models  that  Incorporate  communication  and  computer 
resources.  It  may  also  be  necessary  to  develop  prototype  software  to 
demonstrate  critical  algorithms,  control  sequences,  timing,  or  operator 
interfaces.  The  software  development  cycle  applies  to  prototype 
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developments,  but  it  may  be  tailored  if  the  software  will  not  carry  over 
into  the  FSD  phase. 

i.  Independent  Verification  and  Validation  (IV&V).  The  ACRMP  wi I  I 
assess  the  need  for  IV&V  and  recommend  the  appropriate  level,  scope,  and 
source  to  the  PEO  or  program  manager.  The  program  manager  will  determine 
the  requirements  for  IV&V,  obtain  a  source  of  IV&V,  determine  the  access 
that  the  IV&V  organization  must  have  Into  the  development  contractor’s 
effort,  and  plan  for  providing  that  access.  Document  IV&V  decisions  will 
be  documented  in  the  ACRMP. 

j.  Software  Quality  Evaluation.  The  overall  software  quality 
evaluation  program  for  the  software  development  lifecycle  will  be 
defined.  Responsibility  for  evaluating  computer  software  products  and 
procedures  may  be  assigned  to  more  than  one  organization,  including  an 
independent  organization  (for  example,  the  IV&V  or  operational  testing 
or  gan i zat I  on)  . 

k.  Configuration  Management.  Definition  of  the  overall  approach  for 
configuration  management  of  computer  resources  will  be  completed  during 
the  Ocmonstr at  I  on  and  Validation  Phase. 

1  4.3  2  Automation  and  Communication  Resource  Working  Group  (ACRWG)  -  The 
ACRWG  selects  the  best  hardware/software  support  concept  which  best  fits 
the  system  and  mission  as  stated  in  the  Operational  &  Organizational  (O&O) 
Plan,  ROC.  and  System  Operational  Concept.  The  support  concept  will  be 
described  in  sufficient  detail  to  account  for  system  percu I  I ar 1 1 1 es  and 


existing  conditions. 


The  ACRWG  will  update  the  ACRMP  for  the  AFV  Task 


Force  Director  or  PEO  approval. 
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d.  ACRMP.  Prior  to  the  conclusion  of  the  Demonstration  and 
Validation  Phase  the  ACRMP  will  be  signed  by  the  AFV  program  office  and 
coordinated  with  TRADOC  and  AMC .  Preparation  of  the  final  version  will 
or.Mir  as  soon  as  possible  during  this  phase  to  accommodate  resource 
allocation  and  FSD  planning.  All  ACRMP  chapters  with  the  exception  of 
Deployment  and  Post  Deployment  Support  will  be  finalized. 

b.  Concepts,  Specifications,  and  Plans.  Products  produced  during 
Concept  Exploration  will  be  updated  and  validated.  As  a  minimum  the  total 
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top-level  System  Design  Review  will  be  held.  It  is  envisioned  that 
products  associated  with  the  preliminary  or  critical  design  review 
(M I L-STD-2 1 67 )  will  or  may  be  required  in  draft  or  final  form 

c.  Reviews.  A  System  Design  Review  (SDR)  will  be  held  early  (see 
MIL-STD-  (521)  to  formally  assess  the  allocated  system  requirements  before 
proceeding  into  preliminary  design  of  the  computer  hardware  and  software 
configuration  items.  The  SDR  will  authenticate  the  System/Segment 
Specification.  Additional  reviews  are  planned  to  support  system 
development  configurations. 

d.  Contracting.  The  AFV  Task  Force  or  PEG  will  solicit  request  for 
proposal  (RFP)  inputs  from  using  and  supporting  organizations.  The 
identification  of  automation  and  communication  in  the  work  breakdown 
structure  (W8S)  will  be  in  sufficient  detail  to  ensure  adequate  visibility 
and  management  control  and  to  outline  the  program  to  potential 
contractors.  Requirements  concerning  suppor tab i I  I ty ,  computer  resource 
technology,  configuration  I  tern  allocation  (between  mission  and  system 
software),  access  for  the  IViV  organization,  and  software  development 
methodology  must  be  reflected  in  statement  of  work  tasks  or  compliance 
documents . 

1.4. 3. 4  Demonstration  Validation  Phase  Objectives  -  At  the  conclusion  of 
Demonstration  Validation,  sufficient  information,  data,  and  management 
plans  must  be  collected  and  documented  for  a  Milestone  II  decision. 

1.4.4  Full  Scale  Development  (FSD)  Phase  -  During  the  FSD  phase,  design, 
fabricate,  test,  and  evaluations  of  the  hardware,  software,  facilities, 
personnel  subsystems,  training,  and  the  principal  items  necessary  for 
support  will  be  conducted.  Products  will  closely  approximate  the 
production  item  and  support  equipment  and  will  meet  the  stated  performance 
r  equ I r emen ts . 


a.  Hardware/Software  Development.  Software  and  hardware  to  include 
communication  system  development  entails  the  six  phases  of  the  traditional 
development  cycle.  Although  they  are  described  as  sequential  phases,  a 
top-down  development  approach  may  cause  them  to  occur  concurrently,  with 
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iiiftiTent  portions  of  a  configuration  item  being  developed  in  parallel  and 
(■d(  i>  prirtiiin  proceeding  through  the  six  phases  sequentially 


Figure  1-2.  Hardmre/ Software  Development  Cycle 


h  System  Integration  and  Testing.  Successively  Integrate  CSCIs  end 
HWi.is  and  test  to  validate  that  the  complete  system  is  properly  integrated 
and  meets  system  requirements.  Participation  of  the  using  and  supporting 
or  qan  I  ,?at  I  ons  in  system  testing  is  recommended. 

c.  Development  Test  and  Evaluation  (DTiE) .  The  program  office  will 
ensure  that  software  expertise  is  available  during  DT&E  to  provide  a  valid 
technical  assessment  of  the  system. 

d.  Operational  Test  and  Evaluation  (OTiE) .  The  program  office  and 
tf'e  supporting  organization  will  ensure  that  software  expertise  is 
available  during  OTiE  to  support  the  evaluation  of  the  operational 
effectiveness  and  suitability  of  the  computer  resources  In  the  system . 

e  Independent  Verification  and  Validation  (I V&V ).  Provisions  for 

IV&V  (organizational  agreements  or  contracts)  must  be  in  place  early  m 
the  FSD  phase.  Army  organizations  participating  in  IViV  will  be 
identified  by  the  same  date.  The  implementing  connmand  wl I i :  (1)  define 

1-’ I  control  the  interface  between  the  IViV  agency  and  the  development 
r.di  tr  ac  f  or  ,  (2)  provide  the  IV&V  agency  with  copies  of  appropriate 

di’v  i’ '  cpmen  t  specifications,  design  documents.  listings,  and  technical 
,1,1'H,  and  f3)  resolve  all  discrepancies  found  during  IViV. 

f  Software  Quality  Evaluation.  The  program  office  will  evaluate 
nrittware  quality  throughout  this  phase  for  all  software  development 
,ji  tivir'c>s  and  products 


1 .  n 
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g.  Configuration  Management  The  program  office  Mill  continue  to 

apply  formal  configuration  management  (change  control)  to  automation  and 
conttiun  1  ca  t  I  on  resources  throughout  this  phase. 

h.  SoftMare  Support.  The  program  office  Mill  plan  to  acquire  the 

dedicated  hardMare  and  softMare  necessary  to  support  the  system  under  the 
support  concept  described  in  this  ACRMP  The  softMare  support 
or  gar  1 2a t 1 ons  miM  participate  in  development  and  testing  activities  at 
the  contractor's  facility  and  at  the  system  integration  and  test  facility 

’  442  Automation  and  Communication  Resource  IKorking  Group  (ACRWG) 

a  The  ACRWG  Mill  update  the  ACRMP  as  necessary  and  m  i  I  I  mo  n I t  o  r 
program  comp! lance  Mith  the  contents  of  the  ACRMP. 

b  When  softMare  support  responsibilities  are  split  betMeen 
cormtands,  the  ACRWG  Mill  categorize  each  Computer  (Communication)  System 
Configuration  Item  (CSC  I )  as  e  i  ther  a  mission  or  system  CSC  I .  This  Mill 
be  done  after  authentication  of  the  allocated  baseline  Mhen  the  systems 
CSC's  have  been  defined.  The  ACRWG  Mill  then  reconiDend  assignment  of 

support  responsibilities  for  each  CSC)  m  accordance  with  the  sottMaro 
support  concept  If  agreement  is  not  reached  on  the  assignment  ot 

softMare  support  responsibilities  after  thorough  technical  reviCM  by  thn 
ACRWG  or  developing  contractor,  the  operating  command  conviction  miii 
pr  eva  I  I  . 

0  The  ACRWG  Mill  recormend  the  grouping  of  Computer  System 

Configuration  I  terns  into  Computer  Segments. 

J  the  ACRWG  miM  document  the  above  recommendations  in  the  ACRMP 
1  4  4  3  Automat  i  on  and  Corrmun  i  cat  i  on  Resource  Planning 


a  ACRMP  The  ACRMP  Mil  I  be  updated  to  reflect  the  results  of  life 
cycle  planning  activities  and  to  reflect  relevant  program  changes  It 
Mill  be  completed,  coordinated,  and  signed  by  the  end  of  this  phase 

b  Development  Rev  I bms .  The  imp  I ementa t i ng  agencies  Mill  normally 

conduct  the  follOMing  softMare  development  revievys  during  this  phase 
SoftMare  Specification  RevleM  (SSR) ,  Preliminary  Design  RevieM  i  I’DH i  , 
O't'cai  (leslgn  Revi cm  (CDR),  Test  Readiness  Revi eM  { TRR )  ,  Func  t  i ci ■ 
Configuration  Audit  (FCA),  Physical  Configuration  Audit  (PCA),  and  Furmai 
Qualification  RevieM  ( FOR) . 

c  Production  Approval,  Prior  to  approving  computer  resources  foi 

production.  the  functional  and  allocated  baselines  Mill  be  current,  the 
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(ormdl  Qualification  Review  (FQR)  will  be  completed,  the  product  baseline 
will  be  estabi Ished,  al I  three  base  I  I nes  will  be  under  proper 
ron f I gur at  I  on  control  In  accordance  with  MIL-STD-2167  and  the  support 
concept  will  be  established  and  coordinated 

I  444  FSD  Objective  -  To  be  determined. 


'  4  b  Pr  oduc  t  i  on  Phase  -  The  Production  phase  begins  with  the  production 
dec  ision  and  ends  when  the  last  system  has  been  del ivered  and  accepted. 
Ti'P  maior  I ty  of  planning  will  be  complete  before  entering  this  phase, 
runtnue  planning  related  to  production  and  transition.  Resolve  all 
computer  resources  lifecycle  planning  issues  and  review  the  ACRMP  to 
eusu' that  It  adequately  addresses  production  and  deployment  phase 
a(  t ' V  I t I es  The  f o I  lowing  par  agraphs  will  be  deve I  oped  dur 1 ng  subsequent 

r  f  1/ I I  not,  of  the  ACRMP. 
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1.4.6  Deployment  Phase  -  The  Deployment  phase  begins  with  fielding  of  the 
first  article  and  terminates  wnen  tne  system  is  removed  from  the 
operational  inventory  This  chapter  applies  to  the  operation  and  support 
of  system  computer  resources  during  the  Deployment  phase,  with  particular 
attention  to  software  support.  This  paragraph  will  be  developed  further 
during  subsequent  ACRMP  updates. 

’  S  PROGRAM  STRUCTURE 

1  6.1  Management  -  The  complexity  and  magnitude  of  the  AFV  program 

dictates  a  corrmensur ate  management  structure  capable  of  resolving  the 
program's  fundamental  integration,  configuration  management,  testing,  and 
■nterface  control  challenges.  The  OiO  Plan  extract  at  Figure  1-3  serves 
to  illustrate  the  complexity  of  the  AFV  program. 

1.5.2  Concept  Exploration  Phase  -  During  Concept  Exploration  Phase 

(FY88-89) ,  management  will  continue  to  reside  with  the  AFV  Task  Force 
supported  by  the  Department  of  the  Army  (DA)  Staff,  AMC ,  and  TRADOC 
Contractor  teams  will  carry  through  in  the  development  of  alternative 
approaches  to  the  family  of  vehicles  as  described  below.  During  the  later 
part  of  concept  exploration  or  early  demonstration  validation,  it  is 
envisioned  that  the  AFVTF  will  evolve  into  a  formal  Program  Executive 
Office  (PEG)  reporting  to  the  Army  Acquisition  Executive  (AAE) .  Award  of 
a  Systems  Engineering/Technical  Assistance  (SETA)  system  integrator 
contract  concurrent  with  the  establishment  of  the  PEO  is  planned.  This 
contractor,  in  concert  with  the  established  Project  Management  Offices 
(exact  number  to  be  determined)  and  an  appropriate  AMC  Major  Subordinate 
Connmaiid  (s )  (MSC)  will  assist  the  PEO  in  carrying  out  his  assigned 
r  espons i b i I  i t i es . 
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l.b.3  Demonstration  and  Validation  Phase  -  Given  a  Milestone  I  go  ahead 
de( ision  to  enter  into  this  phase  during  the  4th  Qtr  FY09,  selected 
hardware  prime  contractors  will  assume  management  responsibility  for  the 
der^ign,  fabrication,  integration,  and  test  of  AFV  prototype  systems.  A 
Milestone  II  Full  Scale  Development  decision  in  the  late  FY92  will  result 
in  a  similar,  expanded  program  structure. 

1  h  4  Full  Scale  Development  -  To  be  determined. 

155  Production  and  Deployment  -  To  be  determined. 

I  56  Government  Agencies  -  Due  to  the  nature  and  complexity  of  the  AFV 
program,  almost  all  of  the  TRAOOC  and  AMC  subordinate  commands,  schools, 
,irui  renters  will  be  involved  In  the  development  of  the  AFV.  Specific 
'  i'‘-.pnris  I  b  I  I  i  1 1  es  have  been  identified  and  are  discussed  in  Chapter  3. 

1  h  CONTRACTING  STRATEGY 

1  f'  1  C(  ncept  Exploration  -  Given  the  nature  of  this  program  it  is 
p'lssibie  that  multiple  prime  contractors  may  be  selected  to  execute  the 
Cnr.r.ept  Exploration  Phase. 

'  fi  2  Government  Furnished  Equipment  (GFE)  -  As  with  most  major  programs, 
sr  nf;ted  government  developed  systems  will  be  furnished  to  the  selected 
h.uUwarp  prime  contractors.  The  AFV  program  has  a  fundamental  design 
p- em  ■5G  to  maximize  component  commonality  and  modularity.  It  is  the 
if>*pnt  to  establish  minimum  essential  levels  of  commonality  prior  to  the 
I).  n,ir:.;tr  at  I  nn  and  Validation  Phase.  These  decisions  will  influence 
run t f ac t’r  Selection  of  components,  out,  at  this  time  it  is  the  intent 
tiijt  cunuionents  will  be  contractor  furnished  items. 
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AFV  O&O  REQUIREMENTS,  TOP  LEVEL 


COMMAND  AND  CONTROL  SYSTEM 
SUPPORT  AIRLAND  BATTLE 
EN  LEVEL  C2  SUPPORT-BMS 

INTEGRAL  ION/ INTERFACE  WITH; 

ADM  IN/ LOG  I  ST  ICS 

POSITION/NAVIGATION 

W/OTHER  VEHICLES 

ACCS-SIGMA  STAR  POINTS  INTERFACE 

F IRE  CONTROL-WEAPON,  IMPROVED 

ENVIRONMENT  CONTROL 

BMS  (VEHICLE  CONTROL) 

AUTOMATED  ROUTINE  C2  FUNCTIONS 

BUILT  IN  TRAINING  MODULES 

COMMUNICATIONS  -  DATA  AND  VOICE 
COMMUNICATIONS  COMMON  W/AFV 

hardware 

COMMON  DISPLAYS  (HARDWARE) 

DRIVER  01  SPLAY/HARDWARE,  COMMON 
COMMANDER  0  I  SPLAY (S) /HARDWARE 

THREAT  ENVIRONMENT 

EMP  PROTECTION,  NEEDED 

ECM  PROTECTION,  NEEDED 

HPM  PROTECTION,  NEEDED 

ANTENNAE  PROTECTION  AGAINST  ARTY 

AVOID  UNIQUE  SIGNATURE 

NBC  PROTECT lON/OETECT lON/ALARM 

PRODUC I B I L I TY/COMMONAL I TY 
MODULAR  DESIGN 
COMMONAL I TY 

RECONF IGURABLE  CAPABLE 
VETRONICS,  COMMON  ARCHITECTURE 
NATO  INTERFACE 
AUX  POWER  UNIT 


MAINTENANCE 

BUILT  IN  TEST  (BIT) 

DIAGNOSTICS 
PROGNOSTICS 
GRACEFUL  DEGRADATION 
AUTO  LOGBOOK  (LSA/LSAR) 

INTERFACE  W/TMDE 

OPERATION  SUPPORT  ENVIRONMENT 
CONTINUOUS  OPERATION 
EASY  INTERFACE,  SIMPLIFY  CREW  OUT  IE 
6-96  PERCENT iLE  SOLDIER  USE 

AtJTENNAE 

QUICK  ERECT  (SELF  CONTAINED) 
NAVIGATION 

POSITION/NAVIGATION  GENERAL 
ROBOTICS 

ROBOTICS  WHEN  POSSIBLE 
AUTOLOADER 

REARM  W/0  EXPOSING  (RAPID) 

REFUEL  W/0  EXPOSING  (RAPID) 

RESUPPLY  W/0  EXPOSING 
NBC  SAMPLING 

AUTO  COUPLING  (TOW  VEHICLE) 

MINE  DETECTION 
MINE  CLEARING 

P3I  POSSIBILITIES,  PLAN  FOR 
MOBILITY 

STATIC,  OPERATION 
ON  THE  MOVE,  OPERATION 
VARIABLE  CLIMATIC  OPERATIONS 


FIGURE  1-3 
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1  8.3  Demonstration  and  Validation  Alternatives  -  The  initial  study  phase 
of  the  AFV  program  has  been  carried  out  using  two  or  three  competitively 
selected  teams  under  the  Firm  Fixed  Price  (FFP)  contracts.  In  the 
interest  of  continuity  and  In  view  of  the  compressed  development  program, 
tfiese  same  teams  will  be  maintained  during  the  balance  of  FY08-89.  Based 
on  the  results  of  this  phase  and  a  go  ahead  decision  at  Milestone  I,  the 
intent  is  to  compete  the  Demonstration  and  Validation  (Dem/Val)  Phase  of 
tt>e  program.  Two  alternatives  are  currently  under  consideration  as 
foil ows : 


o  The  first  alternative  is  based  on  carrying  only  one  version  of 
tfte  family  through  the  Dem/Val  Phase  of  the  program.  In  this  case  a 
multi  scope  RFP  which  will  allow  qualified  firms  to  compete  for  the  entire 
family,  or  for  any  subsystem,  or  set  of  subsystems  is  envisioned.  In  this 
manner,  smaller  firms  possessing  specific  capab i I  1 1 i es/strengths  w i I  I  be 
able  to  compete  on  an  equal  basis  with  larger  firms  having  broader 
rauab I  I  1 1 i es .  Although  this  alternative  features  competition,  it  is 
'  tm  ted  to  a  paper  competition  resulting  in  one  version  of  AFV  hardware. 

0  The  second  alternative  is  to  follow  the  same  process  described 
above  but  to  select  two  sets  of  contractors  producing  competing  hardware. 
In  either  case  it  Is  planned  to  execute  this  phase  of  the  program  under 
Cocf  Plus  Incentive  Fee  (CPIF)  contracts.  Incentive  awards  will  be 
principally  base  on  technical  and  support  considerations 

1  h  T  f-iill  Scale  Development  -  To  be  determined. 


!  '  h  Hr oduct i on/Dep I oyment  (P/D)  -  For  the  P/D  phase  of  the  program,  it 
's  planuf^d  to  award  2  successive  single  year  Firm  Fixed  Price  Incentive 
(TFPI)  urintracts  followed  in  the  third  year  by  the  first  of  a  series  of 
h  vi.'u  multi-year  contracts.  Incentives  will  be  based  on  design  to  cost 
and  '  iippor tab  I  M ty  goal  attainment.  In  addition,  the  AFV  fleet  will  be 
I  u/pi fd  by  warranty  provisions.  This  paragraph  will  be  refined  in  future 
ui’iiat  I  nq  of  the  ACRMP. 
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1 . 7  APV  DEVELOPMENT  SYSTEM  METHODOLOGY 


’.7.’  Sc'ftwa'-e  Development  System  Methodology  -  The  complexity  of 
functions  and  variations  in  the  hardware  configurations  associated  wiir, 
the  AFV  the  development  and  support  of  mission  critical  computer 
components  will  require  a  software  development  and  integration  technical 
and  managerial  system  that  embodies  all  of  the  characteristics  demanded, 
^he  system  must  produce  complete,  tested,  and  integrated  software 
components  to  be  fielded  concurrent  with  hardware.  The  development  system 
therefore  must  be  able  to  manage  the  production  and  integration  of 
software  components  produced  from  a  variety  of  sources.  Software 
development  must  be  able  to  specify  standards  and  interfaces  from  the  top 
down  under  an  accelerated  program.  The  system  must  be  able  to  rapidly 
test  and  evaluate  software  module  performance.  The  system  must  produce 
software  that  is  efficient  in  its  use  of  hardware  resources.  The  use  of 
standard,  common,  and  reusable  software  components  will  be  maximized.  The 
system  must  be  able  to  provide  software  maintenance  and  support  over  the 
life  cycle  of  the  APV  and  therefore  must  be  flexible  and  it  must  be  able 
to  produce  revised  software  configurations  efficiently.  In  all  Army 
Mission  Critical  Computer  Resources  (MCCRs)  the  development  of  hardware, 
accortipany  I  ng  software,  and  documentation  proceed  through  the  system  life 
cycle  concurrently.  The  system  will  not  be  approved  for  advancement  to 
the  next  acquisition  phase  until  hardware,  software,  and  documentation 
have  satisfied  all  requirements  of  the  earlier  phase. 

172  Hardware  Development  System  Methodology  -  AFV  hardware  components 
will  be  modular,  will  interface  to  a  standard  bus,  will  be  designed  to 
continue  to  provide  the  most  critical  functions  when  operating  at  less 
than  full  capabiiity,  wili  provide  excess  capacity  to  accomodate 
preplanned  product  improvements  and  will  contain  self  test  diagnostics  and 
pi-ognost  I  cs  . 
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1  7  3 


Communication  System  Development  Methodology  -  AFV  requires  voice 


and  data  communication  subsystems  to  support  vehicle  command  and  control 


functions.  Army  command  and  control  subordinate  communication  subsystems 
are  planned  to  be  integrated  into  AFV  subsystems. 


SCOPE 


This  document  focuses  on  the  planning,  acquisition. 


development,  testing,  training,  and  support  for  the  life  cycle  of  the 
Armored  Family  of  Vehicles  (AFV)  communication  and  computer  resources. 


1.8.1 


Organization  of  the  ACRMP  -  In  order  to  address  the  complexity  of 


f;omputer  resources  management  as  described,  this  ACRMP  has  seven  Chapters; 


general,  requirements  analysis,  program  management,  acquisition 


management,  development  management,  test  and  evaluation,  and  a  plan  for 
support.  Refer  to  the  Executive  Summary  at  the  beginning  of  this  ACRMP 
for  3  by  chapter  summary. 


Computer  Resource  Acquisition  -  Computer  resources  must  be 


considered  during  each  phase  of  the  acquisition  cycle  and  at  each 


rn  i  I  estone  , 


Development  of  computer  resources  necessitate  clear 


specification  of  requirements,  appropriate  allocation  of  functions  between 


hardware  and  software,  and  a  division  of  large  systems  into  manageable 
subsystems.  The  software  milestones  and  attainment  criteria  emphasize 
ttiose  actions  that  must  be  satisfactorily  completed  prior  to  progressing 
from  one  system  acquisition  phase  to  the  next. 


1  .  fl  3 


Communication  Resource  Acqu i s i t i on  -  Commune i at  I  on  resources  will 


also  be  considered  during  each  phase  of  the  acquisition  cycle.  In 
particular,  communications  supporting  other  AFV  functions  such  as  data 
transfer  and  computer  resources  must  be  considered  along  with  the 


sufiported  functions. 
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1 . 9  SYSTEM  REQUIREMENTS 

1.9.1  System  Performance  -  AFV  requirements  for  automation  and  resources 
are  analyzed  in  Chapter  2  of  the  ACRMP.  A  summary  of  these  requirements 
is  shown  in  Figure  1-4.  The  requirements  include  external  interfaces  as 
/lie  I  I  as  internal  components.  In  addition  system  processor  (s)  arch  i  tecty  e 
shall  exhibit  graceful  degradation.  It  shall  strive  for  automatic 
reconf  i  gurat I  on  of  remaining  processing  and  bus  resources  with  the  loss  C' f 
any  unit.  The  goal  is  to  achieve  maximum  performance  and  integration  at 
each  mission  work  or  fighting  station  within  the  vehicle. 

1.9.2  Software  Classification  -  It  is  planned  that  all  software  programs 
will  be  unclassified.  Any  classified  information  processing  will  be 
minimized  and  accomplished  using  a  classified  date  otse  separate  from  the 
unclassified  data  base.  This  data  base  will  be  removable  with  provisions 
to  erase  the  memory  or  physically  destroy  the  unit  on  vehicle 
destruction.  Tactical  critical  software  will  have  highest  priority  and 
will  be  partitioned  from  non-tactical  critical  software  based  on 
operational  efficiency. 

1.9.3  Prograrminq  Languages  -  For  each  of  general  category  of  processing 
(signal,  general  data)  only  one  programming  language  will  be  used. 
Ml L-STD-1815A  Ada  is  required  for  use  on  all  general  data  processing,  fire 
cont'^ol,  training,  ground  support  equipment,  and  signal  processor  control 
systems,  it  is  required  that  Ada  be  used  wherever  practical  in  all  other 
systems  (i.e.,  expert  systems,  array,  and  vector  processors). 

1.9  4  So  f  twar  e  Des i qn  -  A  modular  software  design  will  be  employed  tn 
facilitate  compilation  of  Individual  modules,  testing,  and  system 
c on t  I  gur a 1 1  on .  The  AFV  system  software  will  be  developed  as  an  integrated 
software  package.  The  Utility  software  will  be  a  subset  of  the  vefiicle 
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FV  Requirement  Suitmary 

INTERCOM  WITH  NOISE  SUPPRESSION 

AUXILIARY  POWER 

EXTERNAL  LOCAL  AREA  NETWORK 

COMMON  MISSION  WORK  STATIONS  (Driver,  Gunner,  FV  Conrfnander  , 
Staff) 

POSITION  NAVIGATION  (Position,  Altitude,  Azimuth,  Digital 
suppor  t ) 

ARMY  COMMAND  AND  CONTROL  SYSTEM  (ACCS)  INTERFACE 

VEHICLE  DEFENSE  SYSTEM 

DATA  DISTRIBUTION  (EPUU,  SINCGARS) 

AREA  COMMUNICATIONS  (Mobile  Telephone) 

COMMUNICATIONS  CONTROL  w/CEOI 

COMBAT  NET  RADIO  (Short  Range,  Long  Range) 

BATTALION  AND  BELOW  COMMAND  AND  CONTROL  (B2C2) 

FIRE  AND  WEAPON  CONTROL 
NBC  (Detection,  Protection) 

FIRE  EXTINGUISHER/SUPPRESSOR  SYSTEM 

ENVIRONMENTAL  CONTROL/LIFE  SUPPORT  SYSTEM 

TRAINING  MODULE  (Operations,  Maintenance,  Mission,  Shoot) 

MISSION  EQUIPMENT  OPERATIONAL  SUPPORT  MODULE 

COMBAT  SERVICE  SUPPORT  STATUS  MODULE 

COMMON  VEHICLE  CONTROL/OPERATION  MODULE 

VOICE  RECOGNITION  SYSTEM  (P3I) 

EXTERNAL  TMDE  INTERFACE 
INTERNAL  DIAGNOSTICS/PROGNOSTICS 
BUILT  IN  TEST  (BIT) 

EVOLUTIONARY  COMBAT  IDENTIFICATION  SYSTEM  (CIS) 


Figure  1-4 
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operational  modules.  Embedded  training  modules  are  planned  to  be  a  subset 
of  tne  on-board  application  software. 

1.9.5  Hardware  Design  -  It  is  envisioned  that  hardware  design  will  be 
modular  with  standard  power,  data,  and  mechanical  interfaces.  01 
particular  importance  is  the  standardization  of  data  entry  and  dispijy 
hardware  at  the  FV  stations.  Hardware  components  will  be  designed  lot 
ease  of  insertion  and  removal.  Unless  explicitly  noted  otherwise  the  tprrri 
hardware  refers  to  automation  and  communication  equipment. 


1.10 


AUTHORIZATION 


The  preliminary  ACRMP  was  prepared  under  the 


guidance  provided  by  the  Director,  AFV  Task  Force  (DAMO-AFV) .  It  is  the 
primary  document  used  for  management  of  computer  and  communication 
resource  development  for  the  Armored  Family. 


1.11 


ADM  I N I STRAT I  ON  -  The  ACRMP  will  undergo  evolutionary  changes  as  the 


program’s  plans  develop  and  change  through  its  life  cycle.  It  will  be 
updated  periodically  before  each  milestone.  Appropriate  or gan i za t i ona I 
elements  of  the  Army  will  review  and  provide  recommendations.  The 
Director,  AFVTF  has  overall  responsibility  for  the  ACRMP.  The  Deputy 
Director,  Materiel  Development,  AFVTF  chairs  the  ACRWG  which  will  maintain 
the  ACRMP. 

1.12  ACRMP  RECOMMENDED  CHANGES  -  Concerns,  comments,  and  recommended 
changes  are  highly  encouraged  and  should  be  submitted  on  DA  Form  2028, 
Rfcconmended  Changes  to  Publications  and  Blank  Forms  or  equivalent, 
directly  to  Director,  AFV  Task  Force,  ATTN;  DAMO-AFV-M/Ma j or  Buckstad, 
Fort  Eustis,  VA  23604-5597.  Telephone  AUTOVON  927-1465/6/7  or  (804) 
878-1465  to  discuss  AFV  automation  and  cormiun i cat i on  matters. 
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I  13  SUMMARY.  GENERAL  -  Chapter  1  of  the  ACRMP  describes  the  origins  and 
the  direction  of  the  AFV  program.  Figure  1-5  summarizes  the  objective  for 
Al V  automation  and  communication  system  development. 


OBJECTIVES  FOR  AUTOMATION  AND 

PH^SL  COMMUNICATION  RESOURCE  DEVELOPMENT 

Concept  Exploration  Define  operational  concept  and 

requ I rements . 

Conduct  Analysis  -  Validate  Requirements. 
Top  Level  Specifications  in  place. 

Draft  management  plans  produced. 

MSI  Approval  Concept  with  or  without  changes. 

('cmonstrat ion  and  Validation  Conduct  analysis  and  design. 

Confirm  concept  selection. 

Determine  concept  feasibility. 

Refine  plans  and  specification. 

Ms  I  Development  approval,  required  changes 

ident I f  led  . 

Lull  Scale  Development  Automation  and  Communication  Life  Cycle 

Deve I opment . 

Finalize  plans  and  specifications. 

Production  and/or  fielding  approval, 
required  changes  identified. 

Life  cycle  development  refinement. 

Refine  plans  and  specifications. 

Finalize  fielding  plans. 

Field  system. 

Life  Cyc I e  Suppor  t . 


MS  I  I  I 


Pr  oduct i on 


f'ep  I  oyment 


Figure  1-5.  AFV  Automation  and  Communication 
Resource  Development  Goals 
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CHAPTER  2  -  REQUIREMENTS  ANALYSIS 


2. 1  INTRODUCTION 


Analysis  has  determined  that  computer  resource  requirements  are  divided 
into  three  distinct  parts,  Brigade  and  higher,  Battalion  and  below  C3I 
•functions  (addressed  as  B2C2,  Batalion  and  Below  Command  and  Control),  and 
the  Vehicle  Control  and  Operating  System  (VCOS)  which  is  generally 
composed  o-f  all  internal  functions.  Brigade  and  higher  tactical 
automation  and  communication  requirements  are  handled  by  the  Army  Command 
and  Control  System  (ACCS).  The  ACCS  architecture  will  not  be  redefined  in 
this  document.  It  is  assumed  the  reader  is  famililar  with  the  ACCS 

architecture.  ACCS,  B2C2,  and  VCOS  operational  compatabi 1 i ty  is 

essential.  C3I  at  Battalion  and  below  levels  and  VCOS  is  briefly 
described  in  this  chapter  to  provide  the  basis  for  the  AFV  Required 
Operational  Capabilities  (ROC).  Battalion  C3I  supports  the  commanders  and 
staff  in  fighting  the  force  whereas  VCOS  assists  the  soldier  in  fighting 
the  vehicle.  B2C2  and  VCOS  concepts  originated  from  the  Battlefield 

Management  System.  However,  there  is  a  logical  separation  of  C3I  and 

vehicle  control  functions  to  allow  for  parallel  development.  An 
individual  Fighting  Vehicle  (FV)  may  contain  a  range  of  e.:ternal  C3I 
interfaces  depenoing  on  the  use  of  the  PV  at  battalion,  company,  or 

platoon  level.  All  FV's  will  contain  a  basic  suite  of  internal  autcmatec 

functions  augmented  according  to  vehicle  type  with  specialized  functions. 
Figure  2-1  summarizes  the  external  and  internal  automation  and 
communication  components  for  the  AFV.  This  chapter  will  be  modified  as 
required  when  the  Combined  Arms  Center  (CAC)  defines  and  finalizes  the 
B2C2  and  VCOS  system  definitions. 
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AFV  C4  Components 


VEHICLE  CONTROL  4  OPERATING  SYSTEM  (VCOS) 

INTEGRATED  COMMAND,  CONTROL,  COMMO,  INTEL  (C3I) 

ARMY  COMMAND  CONTROL  SYSTEMS  (ACCS) 

BATTALION  4  BELOW  COMMAND  4  CONTROL  (B2C2)  SYSTEM 

AFV  CANDIDATE  MATERIEL  SOLUTION 


Figure  2-1 
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2.2  BRIGADE  AND  HIGHER  C3I  ELEMENTS 

The  Army  Command  and  Control  Subordinate  Subsystems  (ACCSS)  comprise  the 
Brigade  and  above  archi tecture.  These  systems  include: 

COMMAND  AND  CONTROL  (C2)  Systems 

o  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS) 
o  All  Source  Analvsis  System  (ASAS) 
o  Combat  Service  Support  Control  System  (CSSCS) 
o  forward  Area  Air  Detense  Command,  Control,  and 
Intelligence  (FAADC2I) 

0  Maneuver  Control  System  (MCS) 

Communications 

0  Enhanced  Position  Location  Reporting  System  (EPLRS) 
o  Joint  Tactical  In-formation  Data  System  (JTIDS^ 
o  Single  Channel  Srcund  Airborne  Radio  System  (SIN'CSARS) 
c  "^crile  SuOSC'-’-ter  Equiprr.o'it  '’^SE; 


oossioly  CSSCS’,  plan  tor  integrated  C2  below  Battalic''-  level  within  tnei^ 
mission  area.  Air  Land  Battle  (ALB^  requires  Armv  Com,mand  and  Ccrt^cl 
Subordinate  Systems  (ACCSS)  to  interface  with  the  &2C2  system. 
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2.3  BATTALION  INTEGRATED  03 I  ELEMENTS 


ALB  requires  an  integrated  B2C2  system  capable  o-f  capturing  command 
in-formation  within  the  Battalion  Commanders  area  of  influence.  Analysis 
of  Battalion  C3I  multiple  mission  area  automation  and  communication 
resource  requirements  indicates  a  need  for  automated  support  in  tactical 
command  and  control  (C2) ,  tactical  C2  feedback,  functional  command, 
control,  and  communications  (C3) ,  and  functional  C3  information  feedback. 
These  information  elements  are  displayed  at  Figure  2-2  along  with  their 
operational  location  at  Figure  2-3.  Figure  2-2  presents  a  summary  B2C2 
definition.  The  overiding  objective  of  this  automated  support  is  to  save 
the  chain  of  command  time  by  reducing  manual  workloads  and  improve 
information  reliability  and  timeliness.  The  B2C2  is  expected  to  be  a 
software  system  supported  by  the  Vehicle  Control  and  Operating  System 
(VCOS)  hardware.  CECOM  is  the  planned  B2C2  software  developer.  CAC  is 
the  combat  developer.  B2C2  must  be  tailorable  to  the  commander's  needs. 
Therefore  B2C2  functionality  must  be  capable  of  support  of  the  myriad  of 
C2  functions  within  the  battalion  force.  Figure  2-4  graphically  portrays 
the  varying  degree  of  capabilities  the  B2C2  system  must  capture  at  various 
positions  within  the  chain  of  command.  This  figure  simply  indicates  that 
the  commander's  B2C2  requirements  are  less  that  the  battalion 

sommander  s  ■-eauirements.  For  e:. ample:  the  unit  dommancer  nas  an 

;  ■'tel  1 1  cence  module  .•.nereas  the  FV  tommanoer  ma-/  or:  .■  rave  tactical  Cl 
inoduies.  c2u2  iTiOd'j.ss  toilow. 


2.3.1  Tactical  Command  and  Control 


Tactical  command  and  control  components  and  procedures  of  B2C2  support  the 
direction,  movement,  and  employment  of  the  fighting  force  on  the 
battlefield. 
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Battalion  and  Below  Command  and  Control  (B2C2) 


ItOB 

No. 

Type 

Information 

Content 

Battal ion 
Principal 

Staff  Action/  Subordinates 

1 nterest  on  Net 

Type 

Net 

Dedicated 
Battal ion 

1  Below  Regt 

Battal ion 
t  Below 

Interface 

ACCS 

Feeder 

Support 

1.0 

Tactical  C2 

Operations  Order 

COR 

ALL 

CO  COR  t 

Voice 

YES 

n/a 

MCS/ALL 

2.0 

Frago 

COR 

S3 

CO  COR  t 

Voice 

YES 

PLT 

MCS 

3.0 

Innediate  Info 

COR 

S3 

CO  COR  * 

Voice 

YES 

PLT 

MCS 

4.0 

Innediate  Guidance 

COR 

S3 

CO  COR  * 

Voice 

YES 

n/a 

MCS 

5.0 

Battle  Graphics 

S3 

S2/S4/FSE 

CO  COR  t 

Data 

YES 

PLT 

MCS/ALL 

e.o 

Tactical 

Operational  Status 

C0fl/S3 

S1/S4 

CO  COR  t 

Voice/Data 

YES 

PLT 

MCS//1I 

7.0 

Information 

Battlefield 

COR 

S3/S4/S2/FSE 

8  Feedback 

Locations 

1  AHACH 

CO/PLT/FIST 

Data 

YES 

PLT/AHACH 

MCS/Aa 

8.0 

Mission  Capabi 1 ity 

COR 

S3 

CO  COR  i 

Data/Voice 

NO 

FIST/CO/PLT 

MCS/ALL 

9.0 

Functional 

FS  Reg/flesponse 

FSE 

S3/S2 

FIST 

Data/Voice 

NO 

FIST/CO/PLT 

AFATDS 

C3I 

ADA  Varning 

ADA  OFF 

S3/FSE 

ADA  UNIT/CO 

Oata/Voice 

NO 

All  Elements  FAA0C2I 

11.0 

limed  CSS 

S1/S4 

S3 

CO/PLT/SOO 

Oata/Voice 

NO 

All  Elements  CSSC2 

2.0 

NBC/DE  Attack 

COR/S3 

S2 

CO  COR  « 

Data/Voice 

NO 

All  Elements  MCS/ASAS 

13.0 

AOA  Hsn  Results 

AOA  OFF 

S3/S2 

AOA/CO 

Data 

NO 

— 

FAAOC2I 

14.0 

FS  Results 

FSE 

S3/S2 

FIST 

Data 

NO 

FIST/CO/PLT 

AFATDS 

15.0 

Functional 

Routine  Log 

S4 

S3 

CO/PLT/SOO 

Data 

NO 

All  Elements  CSSC2/ALL 

16.0 

Information 

Log  Status 

S4 

S3 

CO/PLT/SOO 

Data 

NO 

All  Elements  CSSC2/ALI 

17.0 

Routine  Personnel 

SI 

S3/S4 

CO/PLT/SOO 

Data 

NO 

Al 1  Elements  CSSC2 

18.0 

Personnel  Status 

SI 

S3/S4 

CO/PLT/SOO 

Data 

NO 

Al 1  Elements  C5SC2 

19.0 

AOA  Status 

AOA  OFF 

S3 

ADA/CO 

Data 

NO 

— 

FAADC2I 

20.0 

Maint  Posture 

S4 

S3 

CO/PLT/SOO 

Data 

NO 

Al 1  Elements  CSSC2 

21.0 

NBC/DE  Posture 

S3 

S2 

CO  COR 

Data/Voice 

NO 

All  Elements  MCS/ASAS 

22.0 

RSTA  and 

SITREP 

S2 

S3 

CO/PLT/SOO 

Data 

YES 

Al  1  Elements  ASAS 

23.0 

Intel  1 igence 

Shell  Report 

S3 

S2/FSE 

CO/PLT/SOO 

Data 

YES 

Al  1  Elements  ASAS 

24.0 

Threat  Graphics 

S2 

S3/FSE 

CO/PLT 

Data 

YES 

— 

ASAS 

25.0 

Target  Info 

FSE 

S2/S3 

CO  COR  » 

Data/Voice 

NO 

SOO/AHACH 

ASAS 

26.0 

Order  of  Battle 

S2 

S3/FSE 

CO  COR  « 

Data 

NO 

— 

ASAS 

100.0 

Vehicle 

Vehicle  Opns  Sys 

XO 

S3/SM0/ALL 

NA 

Internal 

YES 

All 
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B2C2  Requirement  Distribution 


1.0  Tiet  C2 

Operations  Order 

E 

E 

R 

R 

HA 

NA 

NA 

1.0  1  5  para's,  voice  reqd,  data  dist  asst  desired. 

1.1  I  Brigade  interface. 

1.2  )  Coopany  slice. 

1.3  1  Digital  required,  voice  assianed,  network. 

I.S  )  Attached  1  in  area  digit  reqd,  voice  mimed. 
1.7  1  Digital  required,  voice  assimed. 

1.B  1  Connunieate  with  Friendly  Aircraft. 

1.3  )  Designate  who  shoots.  Candidate  P3I. 

2.0 

Frago 

E 

c 

R 

R 

NA 

NA 

NA 

2.0  1  Voice  Required,  Dta  Dist  highly  desired 

2.1  1  Voice  Required,  Ota  Dist  highly  desired 

3.0 

IniMdiate  Info 

c 

c 

R 

R 

NA 

HA 

NA 

3.0  1  Plain  text. 

4.0 

limed  1  ate  Guidance 

E 

E 

R 

R 

NA 

NA 

NA 

4.0  1  Plain  text. 

S.O 

Battle  Oraphies 

E 

E 

R 

R 

fM 

NA 

NA 

5.0  1  Blue  Force,  terrain  desired 

e.o 

Operational  Status 

c 

E 

R 

R 

NA 

NA 

NA 

S.O  1  Unit  Rollup  of  essential  infonution. 

2.0 

Battlefield  locations  E 

E 

R 

R 

NA 

NA 

NA 

7.0  1  Friendly  locations. 

7.1  1  Six  digit  grid,  Aisaiith  1  Alt  for  Shooters. 

7.2  )  Unit  Rollup. 

7.3  >  Prohleei  Areas. 

7.4  1  Attached  or  operating  in  Bn  Area  of  Opns. 

(.0 

yission  Caoabi  1  Ity 

E 

E 

R 

R 

NA 

NA 

NA 

B.O  )  Miuion  ready  or  Not  ready. 

8.1  1  Ready  to  fight. 

8.2  )  Unable  to  fight.  ' 

3.0 

F5  Rep/Response 

E 

E 

R 

c 

E 

0 

NA 

9.0  1  Indirect  Fire,  Naval  or  Air  Support. 

3.1  1  Call  for  fire. 

9.2  1  Rounds  on  or  not  on  the  way. 

9.3  1  FS  plan  distribution  support. 

9.4  1  Use  wortars. 

9.5  1  Rounds  on  or  not  on  the  way. 

10.0 

AOA  Warning 

E 

£ 

0 

c 

0 

E 

10.0  1  Inpound  or  outbound  aircraft  in  area. 

10.1  )  Prepare  to  Threat  attacL. 

10.2  1  Don’t  shoot. 

i:.o 

lirred  CSS 

c 

c 

C 

£ 

0 

z 

z 

11.0  1  lAjst  nave  CSS,  mission  required. 

;;.o 

NSC/CE  Atticl, 

E 

£ 

D 

c 

D 

E 

z 

12,0  1  Unit  attacked. 

:;.o 

AOA  Msn  Results 

E 

E 

0 

ILL 

NA 

NA 

NA 

13.0  1  ADA  unit  in  area,  fire  msn  results. 

14.0 

rS  Results 

E 

z 

0 

R 

0 

NA 

NA 

14.0  1  Results  of  FS  mission. 

15.0 

Routine  Log 

E 

c 

E 

z 

E 

E 

£ 

15.0  1  Request  for  bean,  bullets,  benrine. 

K.O 

Log  Status 

E 

E 

E 

c 

c 

E 

lE.O  1  Essential  equipment  levels. 

17.0 

Routine  Personnel 

E 

E 

E 

E 

C 

£ 

E 

17.0  1  Personnel  matter  status  A  requests. 

11.0 

Personnel  Status 

E  . 

E 

E 

E 

E 

c 

E 

18.0  )  Specific  Soldier  needs. 

13.0 

AOA  Status 

E 

R 

0 

0 

NA 

NA 

NA 

13.0  1  Weapon  posture. 

20.0 

Uaint  Posture 

E 

E 

E 

R 

R 

NA 

NA 

20.0  1  Vehicle  Readiness. 

21.0 

IBC/OE  Posture 

E 

E 

E 

E 

E 

E 

E 

21.0  1  Current  protection  level. 

22.0 

SITREP 

E 

E 

e 

E 

E 

E 

E 

22.0  1  Situation  Report. 

23.0 

Shell  Report 

E 

e 

E 

E 

E 

E 

E 

23.0  I  Threat  inconming  indirect  fire. 

24.0 

2S.0 

Threat  Brapnies 
Target  Info 

E 

E 

R 

R 

NA 

NA 

NA 

24.0  1  Red  Force  pictures,  Ave  of  approach,  locations 
25.0  1 

20.0 

Order  of  Battle 

E 

E 

0 

0 

NA 

NA 

NA 

20. 0  1  Threat  competition. 

Figure  2-3 
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C4  Relationships 


fCCSS  <-  ACCS,  C£CC« 


Battalion  I  Below  Cc 
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2.3.2  Tactical  In -for  mat  ion  and  Feedback 

Tactical  in-formation  and  feedback  is  the  receipt  of  tactical  command  and 
control  information  or  status.  Data  bases  are  updated  and  printed  or 
visual  reports  are  provided. 

2.3.3  Functional  C3I 

Multiple  mission  area  (such  as  engineer,  fire  support  or  air  defense) 
direct  support  information  must  be  processed  and  provided  to  the  chain  of 
command . 

2.3.4  Functional  [C3I]  Feedback 

Foremost  in  C3I  feedback  is  the  acknowledgement  of  receipt  of  functional 
C3I  mission  support  information  and  data. 

2.3.5  Reconnaisance ■  Surveillance.  Target  Acquisition  (R5TA) ,  and 
Intel  1 1  pence 

The  “V  Tiust  be  capable  of  receiving  tactical  intelligence  and  cevelccinp 
the  tnreat  picture. 
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2.4  AFV  VEHICLE  CONTROL  AND  OPERATING  SYSTEM  (VCDS) 

The  AFV  Fighting  Vehicle  requirements  -for  automation  and  communication 
includes  potentially  17  major  subsystems  and  modules.  VCDS  is  the 
electrical  system  architecture  (automated,  communication,  and  inter-face 
components)  resource  manager  capable  o-f  painting  a  well  organized  standard 
picture  -for  the  FV  crew.  Figure  2-4  shows  that  basic  VCDS  functions 
remain  the  same  or  slightly  increased  based  on  the  FV  support  position  in 
the  chain  of  command.  Figure  2-5  shows  the  VCOS  basic  elements  and 
distribution  across  the  chain  of  command.  Figures  2-6  and  2-7  show  the 
distribution  across  the  AFV  fleet  and  summarizes  the  competing 
requirements  for  bussing  and  communications  that  must  be  supported  by  a 
VETRONICS  architecture.  It  is  expected  that  the  .  VCOS  will  host  or 
directly  support  the  AFV  required  B2C2  system.  Tank  and  Automotive 
Command  (TACOM)  is  the  expected  government  VCOS  materiel  developer.  CAC 
is  the  combat  developer.  Discussions  concerning  VCOS  hardware,  software, 
firmware,  communications,  and  modules  follow. 

2.4.1  VCOS  Software 

VCOS  software  runs  or  manages  the  AFV  suos'/stem  con-.poner.ts  tied  into  a 
common  VETRONICS  data  bus(e3;  and  architecture.  ""he  VCOS  software 
provides  all  automated  internal  vehicle  functions  and  the  interface  to 
B2C2  and  ACCS  functional  systems. 

2.4.2  VCOS  Hardware 

The  VCOS  hardware  provides  hardware  access  to  the  VETRONICS  bus  and 
computer  memory  and  storage  for  executing  vehicle  and  fire  control.  It 
must  support  ACCS  functional  and  B2C2  software/hardware.  All  hardware 
must  be  hardened  against  the  directed  energy  threat. 
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AFV  Control  and  Operating  System  Distribution 


Typ« 

1 

1 

In  Cdr  i  Co 

«, 

Pit 

«  1 

•  t 

Pit  :  See/  :  Fighting 

Inforvition 

Content 

1  ;  Cdr 

suff  ; 

1 

1S6 

Ldr 

Sgt  !  Sqd  !  Vehicle 

I  Ldr  !  IFV) 

:  ;  Cdr 

NOTES/COMENTS 

IReferene*  the  item  mnper,  on  left) 

:  100.0 

VEHICLE 

Vehicle  Opns  Sys 

E 

E 

E 

E 

E 

£ 

E 

;  101 .0 

CONTROL 

Data  Bus  Control 

E 

E 

E 

E 

E 

E 

£ 

1  102.0 

and 

Diagnostics 

E 

E 

E 

E 

E 

E 

E 

;  103.0 

OPERATIONS 

Prognostics 

E 

E 

E 

E 

E 

£ 

E 

;  104.0 

Heapon  Control 

D 

E 

E 

E 

E 

E 

E 

;  10S.S 

Environment  Control 

E 

E 

£ 

E 

E 

£ 

E 

;  100.0 

Vehicle  Status 

E 

E 

E 

E 

E 

E 

E 

:  107.0 

Ccorntni  cat  ions 

E 

E 

E 

E 

E 

£ 

E 

!  lOO.O 

Training 

E 

E 

£ 

E 

E 

E 

E 

!  109.0 

Vehicle  Defense 

R 

R 

■  R 

R 

R 

R 

R 

!  110.0 

fork  Stations 

E 

E 

E 

E 

E 

E 

E 

:  111.0 

Mission  Support 

E 

E 

E 

E 

E 

E 

E 

I  112.0 

Notmork  Support 

E 

E 

E 

E 

E 

E 

E 

:  m.o 

Position  Navigation 

R 

R 

R 

R 

R 

R 

R 

i  11^.0 

Cren  Conunication 

E  ■' 

E 

E 

•  E 

E 

E 

E 

■••.Ms.o 

^••0.0 

Spoeiaf  Equipment 

E 

E 

E 

E 

E 

E 

E 

ACCS  Interface 

E 

E 

E 

R  . 

R 

0 

0 

.0 

Power  Spt,  EnglAux 

E 

E 

E 

E 

E 

E 

E 

I  IntffTittd  and  control  fad  von i el*  opKationt. 

I  \/ER0NICS  Arehittcturt,  /U  AFV. 

)  Autonotiv*  and  Electrical  Sys  Status. 

)  Equipment  about  to  or  may  deadline  vehicle. 

)  Integrated  fir*  control  system. 

I  Inside  toiqiKatur*,  fir*  extin  and  WC  protect. 
)  Organized  vehicle  sumarized  status. 

)  External  eoRMunieation  support. 

)  EoMded,  3  levels  of  expertise  auto  eentrol. 

I  Integrate  detection  t  reactive  sys  suites. 

I  Integrated  Duty  work  station  ■/  auto  support. 

)  Uission  auteaatic  support. 

I  Unit  level  tied  together  for  comoo  support. 

)  Location. 

I  Conminicate  within  Fighting  Vehicle  IFVI. 

I  Special  aission  support  equipment. 

I  I  Amy  C2  Systoi  Interface. 

)  Maintain  Operation  of  equipment. 


E*  EsMtiali  R«  Required,  O*  Desired,  0*  Optional 


I  I 

"vtOS  I  lyp,  I  Inrerrtijt 

Ittm  I  tnftrfnatlfft  I  Conttnt 


’0i  ^  \»  \  ion 
Pr  I  nc I p* I 


5ub«rpln«it9  I  Typt 
•n  Ntt  i  Ntt 


1  \ _ 

I  Ovtfiettttf  I  Sattal <on 

I  M  ow  I  I  I 

}  I  Avql  I  Intvrftet 

I  i 


I  ACCS 

I  Ftt4»r 

I  StfP»«r  t 


*Topro“r^^!5 - 

1Q1 .Q  I  Ctntrcf  I 
~ku4«9  I  uptraiisn^ 

IP9.0  I  SrvtfMi 
*104.0  I  IVCOtl 

les.o  t 

•lOCTO-1 - 

tor.o  I 


109.0  I 

no.o  I 

111.0  I 
•111.0  I  • 
119.0  I 


tts.o  I 
n;.o  t 


I  Vfr»r4lf  09«?“Sv»  ■ 

I  Data  Owa  Cantral 
i  DiafnatCdca 
I  ^paff>«atle9 
I  Waapan  Cantral 
I  Envlranmant  Cantral 

7*V«l4irif*Stiliift - 

I  CaaiaMWIcitlana 

I  dfadnin^  “■  ’ 

I  Vahleia  Offtnaa 
I  Wark  t tat  I  ana 
I  Mlaalan  Swapart 
TNatwark  Sappart 
I  Faaltlan  Navifatlan 
Tm5rT5S55n7aa  n  an'T 
I  Spatial  Sttlpaiant  I 

"rKCnhlai»fa4i - ! 

I  Ppwar  Sappprt  t 


'XO - 

Sio 

■^ITTCfFP" 
SIO  Off 
53 
S3 

S3 - 

SIC  OFF 


>  I  I 

i"n7swy7Anr  \  na 

I  S3/0M0/AUL  f  M« 


I  SS/OMO/ALU  I  HA 
1  OMO/ALU  ■’'rNA 
I  S4/0M0/ALU  I  NA 
■*reM07ALC’ — 

\  S3/OMO/ALL  I  NA 


I  Inttrnt 
t  Iwtarwa 
I  Intarna 
I  Inltrna 
*1'lntarna 
I Intarna 
'  r  I  ntarna 


— Tver 

I  VCl 

— r?tr 

I  YES 
I*YE5 
I  YES 

I  TVes" 

r.do.ii^ES 


S3 

SIC  OFF 
S3 

SIC  OFF 
S3 

sic’vr' 

S3 

53  - 

S3 


I  ALL 

I  S3/OMO<M.L 
I  ALL 

1  S3/M0/M.L 
(  ALL 


I  M/ALL 
"I'IMO/ALL  — 
t  OMO/M.L 
1 — I  ftnirr 


I  Unit  • 
t  NA 

-TNa - 

I  NA 

"THA - 

I  NA 


Ail  I  llCJ/lvii” 

HA  I  IVIS»*t 

“ha  7  I VI I 

NA  I  IVIS 

na“  I'lvis 

NA  I  IVIS  _ 

"ap  faau^^W  7 

Aa  rtqulrt4  I  IVIS 

“RX - -  ”1  Ivll - 

NA  I  IVIS 

NA  I  IVIS 

At  raqolrat  I  ivif 

'Aa  ratwirat  I'Hvif 

r  •  1  rvit 


NA  I  IVIS 

NA  r  IVIS 

NA  I  IVIS 

Syil^  Inan-ACCSl 


Figure  2-5 
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VCOS  VETRQNICS  Architecture 
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AFV  Mission  Module  Distribution 
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2.4.3  VCCS  Firmware 

Hardware  items  containing  microcode  programming  will  be  supported  by  VCOS 
when  pertcrmance  requirements  dictate. 

2.4.4  VCOS  Communications 

For  the  purposes  ai  integration  ACCS  communication  subsystems  will  be 
treated  as  a  VCOS  component.  From  a  B2C2  requirement  aetinition  point  o-f 
view  communication  subsystems  (except  the  intercom)  will  be  treated  as  C2 
comoorents. 

2.4.4. 1  I Pter com 

■^he  FV  intercom  susDsystem  provides  internal  voice  communications  to  all 
crew  members.  Intercom  should  be  capable  ot  operating  combat  net  radio 
operations  and  be  product  improved  -for  voice  [computer]  recognition. 

2. 4. 4. 2  Auxillarv  Powe*' 


■ecu',  red 


.  ■  1  ,  ■  - 


i-;ner  eve' 


not  cce-etin 


2.4.F.C  _ccal  Network 


At  the  unit  level,  communications  support  is  provided  by  the  local  network- 
through  physical  connection  (wire,  -fiber  optics,  etc)  or  data 
communi  cat cns. 
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2. 4. 4. 4  Mission  Fighting  Station 

Each  FV  crew  member  operates  a  driver,  commander,  gunner,  or  sta-f-f  member 
station  that  provides  in-formation  and  accepts  commands  for  the  operation 
of  vehicular  and  e:;ternal  functions  appropriate  to  that  station.  Fighting 
Station  components  include  d’splays,  controls,  input,  and  output  devices. 
This  station  will  serve  as  the  soldier's  integrated  cockpit.  (See  para 
2.5,  Standard  Crew  Interface). 

2. 4. 4. 5  Position  Navigation 

This  subsystem  provides  accurate  positional  and  navigational  information 
based  on  the  FV  mission. 

2.4. 4.6  Army  Command  and  Control  System  Interface 

The  ACCS  generally  provides  C3  at  the  Brigade  and  higher  levels.  Selected 
AFV  subsystems  may  contain  ACCS  modules  to  support  their  specific 
mission.  For  example:  the  Fire  Support  Team  (FIST)  will  have  a  AFATDS 
module  and  the  Resupply  module  may  have  a  CSSC3  module.  This  VCC5  design 
module  mav  contain  the  B2C2  system. 


Active  defense  with  passive  and  active  sensor  subsystems  will  oe  comouter 
assisted  to  provide  high  speed  defensive  solutions  based  on  the  FV ' s 
available  offensive  and  defensive  weapon  systems. 

2. 4. 4. a  Data  Communication 

Internal  data  communication  is  supported  by  the  VETRONICS  bus 
architecture.  External  data  communication  is  supported  by  local  combat 
net  radio,  and  area  communications. 
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XV-II-21 


AFV  CRMP 
VOLUME  XV 


1  SEPTEMBER  87 
REQUIREMENTS  ANALYSIS 


-J\SSinED 


2. 4. 4. 9  Area  Communication 

Area  communications  networks  provide  communications  to  higher  and  lower 
units.  Area  communications  will  be  used  primarily  by  the  chain  o-f 
command . 

2.4.4. 10  Voice  Communication 

Voice  communication  caoability  is  orovided  by  area,  local,  and  intercom 
systems.  Voice  communi  cati  ons  is  required  -for  all  AFV  subsystems. 

2.4.4. 11  Oommuni cat: on  Control 

Manual  and  automated  procedures  and  protocols  are  used  to  maintain  control 
ot  conmun:  cat:  ons  systems.  This  control  -function  will  have  a 

pri on ti : at: on  capabilitv. 

2.4.4.12  Fire  and  Weapon  Control 

"V  weapons  and  fire  control  svsteims  I'cl-wde  target  a :  cui  si  1 1  or, , 
09"  c  1  *  1  c  a  0 :  0"  .  ■-leacc"  aeiection,  a-'d  a-o.'ost’a""-  o-  ■‘i-'S  ■“."ctic"E.  ^'".ese 
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2.4.4.14  Embedded  Training 

Training  covering  all  facets  of  vehicle  control  and  operation  are  embedded 
and  available  at  vehicle  fighting  stations.  Embedded  training  should 
cover  the  ability  to  shoot,  maintain,  and  operate  the  vehicle. 
Maintenance  and  operations  training  modules  are  family  common.  A  special 
mission  support  module  should  be  available  for  special  equipment  and 
operations.  See  paragraph  2.5  for  further  information. 

2.4.4.15  Special  Mission  Support  Module 

Specialized  vehicles  such  as  the  Bridge  subsystem  will  require  a  special 
software/hardware  module  for  bridge  erection  and  recovery.  Another 
example  is  a  remote  piloted  vehicle  control  module  which  may  be  housed  in 
the  AFV  command  group  or  intelligence  vehicle. 

2.4.4.16  Combat  Service  Support  Module 

This  module  will  provide  automatic  (or  on  command)  vehicle  status  to  a 
high  echelon  of  command.  This  module  should  be  compatible  with  the  Combat 
Service  Support  Control  System. 

2.4.4.17  Automatic  Looboot: 

The  family  common  required  automated  logbook  compiles  maintenance, 
diagnostic,  and  prognostic  information  for  the  AFV.  Logbook  data  and 
module  must  be  compatible  with  test  maintenance  and  diagnostic  equipment 
(TMDE)  and  be  able  to  capture  Built-in  test  data  from  VETRONICS 
subsystems.  The  prognostics  module  will  initially  capture  vehicle  sensory 
data  (fluid  and  power  levels)  and  technical  manual  (TM)  repair  schedules 
to  project  problem  areas  via  display  or  audio  signals.  Prognostics  module 
computational  power  must  be  preplanned  product  improved  (P3I)  capable. 
The  automatic  logbook  should  have  the  capability  to  run  as  a  background 
task  without  degrading  mission  priority  automation  and  communication 
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2.5  AFV  STANDARD  CREW  INTERFACE  -  HUMAN  FACTORS  ENG  INNER  I NG 

The  number  and  complexity  o-f  the  automated  functions  available  in  a 
Fighting  Vehicle  (FV)  requires  a  standard  crew  interface  to  be  developed 
and  imposed  on  hardware  (data  entry  and  displays)  and  on  applications 
software  (to  include  embedded  training)  in  the  FV.  This  level  of 
standardization  is  envisioned  to  reduce  training  costs. 

2.5.1  Human  Factors 

The  standard  crew  interface  will  specify  standard  formats,  sequences, 
procedures,  performance  criteria,  meanings,  responses,  colors,  audibles, 
and  functions  for  software  and  hardware  interaction  with  the  FV  crew. 

2.5.2  Embedded  Training 

In  addition  to  compliance  with  the  standard  crew  interface,  embedded 
training  standards  for  on-line  help  functions,  tutorials,  practice 
sequences,  performance  evaluation,  audits,  and  template  or  macro  functions 
will  be  specified  and  implemented.  Developed  embedded  training  will 
support  vehicle  and  crew  operations,  vehicle  maintenance,  and  conduct  of 
fire.  Collective  training  (above  vehicle  crew  level)  will  be  initially 
supported  by  a  tethered  local  networ):.  A  stand-alone  (non-AFV)  computer 
may  be  required  to  drive  the  system.  User  and  maintenance  documentation 
will  be  developed  concurrently.  The  Combined  Arms  Center  will  develop 
common  training  requirements  while  the  TRADOC  schools  will  ensure  mission 
unique  requirements  are  properly  developed.  The  AMC  developer  is  to  be 
determined. 
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2.5.3  Standard  Crew  Inter-face  Spec i -f i cations 


The  Inter-face  Control  Board  <ICB)  and  Human  Factors  &  Training  Board 
(HFTB)  operating  under  the  Automation  and  Communication  Resource  Working 
Sroup  will  be  responsible  -for  the  development  and  specification  o-f  the 
standard  crew  inter-face.  The  HFTB  will  also  represent  the  ACRWG  in 
training  and  other  human  resources  matters. 


2.6  METHODOLOGY 


The  methodology  -for  identifying  proponent  agencies  for  management  of  the 
development  and  support  of  AFV  C3  resources  relies  on  the  analysis  of 
requirements.  Figure  2-Q  shows  requirements,  responsible  agencies, 
planned  deployment  level,  and  level  of  FV  need  for  each  capability. 
Requirement  analysis,  refinement,  and  development  will  be  a  continuous 
process  throughout  the  AFV  life  cycle.  This  cycle  will  be  supported  by 
the  AFV  Technology  Assessment  Program  to  ensure  state  of  the  art  and  cost 
effective  technology  (and  system)  are  captured  for  the  AFV. 


2.6.1  Proof  of  Principle  (POP)  Phase 


Identified  activities  (Chapter  3,  Program  Management)  will  play  an 
important  role  in  the  specification,  design,  and  acquisition  management  of 
the  AFV  computer  resources.  During  the  POP  Phase  of  the  AFV  acquisition, 
three  independent  contractor  efforts  to  this  analysis  are  e;:pected  to 
contribute  to  the  final  methodology  for  development  of  the  automation  and 
communications  resources  needed  for  the  AFV.  POP  will  be  completed  for 
the  initial  AFV  fielding  by  FY  89  when  Milestone  I/II  decision  will  be 
made.  At  this  time,  AFV  products  as  listed  in  Appendix  E,  AFV  Requirement 
and  Planning  Documents  will  be  completed. 
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2.6.2  Development  Proveout  (DPQ)  Phase 

During  DPO,  the  development  o-f  automation  and  communications  resources 
will  depend  on  the  selection  o-f  a 

VETRONICS  architecture  and  its  speci -f i cati on ,  the  specification  o-f  the 
Vehicle  Control  and  Operating  System  (VCDS),  and  the  speci-fication  o-f  the 
inter-face  to  the  Battalion  and  Below  Comi.-iand  and  Control  (B2C2)  C3I 
functions.  Candidate  preplanned  product  improvements  (P3I)  or  engineering 
changes  will  pe  developed  or  tested  for  future  AFV  fielding. 

2.6.3  Production  Deployment  (F/D)  Phase 

During  P/D  of  the  AFV,  rapid  and  effective  support  of  automation  and 
communications  resources  will  be  critical.  The  establishment  and 
operation  of  tne  lCSEC  during  DPO  will  permit  this  key  organization  to 
mature  early  and  to  develop  the  management  and  techniques  for  effective 
software  support  throughout  the  life  cycle  of  the  AFV. 

2.7  SUMMARY.  REQUIREMENTS  ANALYSIS 


'^■0  anal  ./sis  of  •■eaui  rements 
automation  and  communication 
-'unotionc.  -'Otenci';  S.  AFV 


IS  based  on  internal  and  e'ternal  needs  for 
as  derived  from  veniole  control  ana  C3I 
Integrated  C3  wnen  cutlished  i^ill  contain, 
'ecui  '"ement  s . 


on  and  communi cationa 
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CHAPTER  3  ■  PROGRAM  MANAGEMENT 

3.1  INTRODUCT ION  -  This  Chapter  of  the  ACRMP  addresses  overall  AFV 
computer  resources  planning  and  philosophy,  and  Identifies  Army  agencies 
and  organizations  that  will  be  involved  in  the  requirements  refinement, 
acquisition,  test,  and  support  of  the  AFV  automation  and  communication 
r  esources . 

.3.2  PERSONNEL  RESOURCES 

3  .  1  AFV  Task  Force  -  The  Task  Force  staffing  will  remain  relatively 
st.iblp  during  Concept  Exploration.  Ail  automation  and  C* I  should  be 
brought  to  the  attention  of  the  AFV  C’l  project  officer  (para  1.12), 
future  organization  staffing  will  be  determined  at  a  later  date. 
Potential  staffing  may  include  appointed  representatives  from  supporting 
..onr.ands  . 

3,2.2  Supporting  Commands  -  Supporting  commands  are  required  to  appoint 
as  d  minimum  a  primary  and  alternate  point  of  contact  to  support  the  AFV 
automation  and  cotrmun  I  cat  I  ons  program.  Command  Action  Officers  are 
■  vfipcted  to  manage  analysis,  design,  and  planning  within  their  respective 
corrmands  in  an  expedited  and  non-trad  1 1  lonal  manner. 

3  3  MANAGEMENT  RESPONSIBILITIES  -  The  implementation  of  the  AFV 
acquisition  strategy  requires  intensified  management  effort.  Traditional 
sequential  management  techniques  will  not  suffice.  The  scope  of  AFV  la 
large,  resulting  In  diverse  combat  developer  requirements  combined  with 
•I'ultiple  system  engineer  or  materiel  developer  approaches  to  system 
S'liutions  Management  and  their  designed  representatives  must  do  their 
par  r  to  insure  that  during; 
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MATERIEL  DEVELOPMENT  PHASES 


OBJECT  IVES 


CONCEPT  EXPLORATION 


DEVELOP  CONCEPTS*,  DEFINE  REQUIREMENTS, 
TOP'  level  SPECIFICATIONS*.  MANAGEMENT 
PLANS*,  TRADE-OFF  AND  FEASiBIlTt 
STUDIES*.  SYSTEM  REQUIREMENT  REVIEW. 


CONCEPT  selection. 


DEMONS'^RAT  I  ON  VAl  I  OAT  I  ON 


CONFIRM  CONCEPT  SELECTION,  R i SE 
REDUCTION,  REFINE  REQUIREMENTS. 

PROTOTYPES,  ESTABLISH  FUNCTIONS 

BASELINE*,  START  DEVELOPMENT Ai 

BASELINE*.  PRELIMINARY  SYSTEM  DESilN 
SPECIFICATION  REFINED,  EsTABl.r'H 

ENGINEERING  CENTERS.  PRELIMINARY  [.lESiGN 
REVIEW. 


full  scale  DEVELOPMENT  APPROVED. 


FULL  SCALE  DEVELOPMENT 


COMPLETE  SYSTEM  DESIGN,  PROGRAM  AN: 
FABRICATE.  FORMAL  TESTING*,  CRlTiiAl 
DESIGN  REVIEW,  MANAGEMENT  P|AN.t, 
FIELDING  PLANS*,  MANUALS* ,  TEbI  AM 
CRITICAL  DESIGN  REVIEWS,  ESTABLISH 
PRODUCT  ION  BASELINE* 


MS  I  I  I 


PRODUCTION  (DEPLOYMENT)  DECISION 


PRODUCT 'ON 


POSSIBLE  CHANGE  REQUIREMENTS*.  CONTlNutD 
LIFE  CYCLE  ACTIVITIES*,  SYSTEM  DEL  I VEH> 
AND  test,  MANAGEMENT  PLANS*,  FlELL'iNU 
PLANS* . 


UEFLOYMENT 


first  unit  equipped,  CONTINUED  LiFf 
cycle  ACTIVITIES.  PRODUCT  IMPROVEMENTS 
PREPLANNED  PRODUCT  IMPROVEMENTS 


*'';arrieiT  forward  fo  the  next  phase  tor  refinement  and  update 


AFV  Management  Object 'ves 
F I gur  e  3-1 


3.2 
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A  Concept  Exploration  -  Requirements  are  defined  and  analyzed, 

B  Demonstration  Validation  -  Requirements  are  confirmed  and  design 
. s  comp  I eted , 

C  Full  Scale  Production  -  Programming,  fabrication  and  testing  is 
completed  vuitfi  supporting  soldier  documentation  and  finally,  during 

0  Production  and  Development  -  The  system  is  ready  for  fielding  and 
life  cycle  suppor  t  is  vwor  kab  I  e  . 

AFV  automation  and  communication  resource  development  objectives.  Figure 
T  1  ,  mup  t  be  a  t  ta  i  ned 

T  T  1  Director,  Armored  Family  of  Vehicles  Task  Force  (AFVTF)  -  The 
Director,  AFVTF  has  the  overall  responsibility  for  the  life  cycle 
management,  development,  and  acquisition  of  the  AFV  computer  resource 
'ems.  and  is  responsible  for  maintenance  of  the  AFV  ACRMP.  The  Director 
•  ae  initiated  the  establishment  of  an  Automation  and  Communication 
Ve-ijurres  Working  Group  (ACRWG)  to  aid  in  the  preparation  and  maintenance 
■  it  ttig  AFV  AACRMP .  The  primary  functions  to  be  performed  by  the  ACRWG 
ini  ude,  but  are  not  limited  to,  the  follOMking; 


A  P'an  for  the  development,  test,  integration,  production,  and 
support  programs  and  set  the  criteria  for  decisions  based  on  all 
factors  that  could  affect  the  system  life  cycle.  These  include: 

o  Operational  and  support  concepts  for  both  hardware  and 
software  resource  Items, 
o  Economic  constraints. 
n  Technology  and  risk  assessment. 

n  Tradeoffs  between  hardware  and  software  applications. 

'I  Scheduling 

■/  Total  vehicle  electronic  architecture  integration. 

H  t'f/.ew  system  integrator  and  contractor  progress  during  system 
development  and  integration  and  maintain  procedures  to  ensure 
deployment  of  the  system  within  program  goals 

insure  timely  completion  of  development  and  operational  testing, 
i'll  coordinate  the  test  results  with  the  responsible  agencien. 


3.3 
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D.  Ensure  that  computer  resources  are  properly  Integrated  in  ir^i 

overall  AFV  system  thereby  providing  tor  the  functional  capabMiiy 
required  ' r  the  automated  battle' leld  environment. 

£  Resolve  a'l  computer  resource  conflicts  that  may  develop  betwveii 

the  B2Cx  interfaces  ano  the  VCOS  Fighting  Vehicle  componeiits 
Ertenalve  Communication-Electronics  Conmand  (CECOM)  and  Prograi 
Executive  Office  ^or  Commun  i  ca  t  ion,  Cormiand ,  Contri,‘,  -in' 
intelligence  &  Electronic  Ul/arfare  (lEW.’  coordination  is  expectei 

F.  Ensure  that  adequate  software  documentation  is  available  t.T 

effective  user  and  post-deployment  support  for  tt'C  fieided  AFv 


Q  BIT  and  "^MDE  integration 

0  Support  of  Microprocessors 

0  Ada/Ada  Environment  Availability 

0  PoKner  (we  I  ght/s  I  ^el 
0  Sof  twar  e  Matur  i  ty 

0  VETRON'CS  Interfaces  and  interconnections 

0  D. agnostics  and  pr ognos t  ■  cs ,  scope 

o  Data  Distribution  Communication  Capability 

o  Digital  Mapping  or  Terrain  Standards 

0  Battalion  Corrmand  i  Control  Architecture 

0  centralized  vs.  Decentralized  Software 

Development  Management 
0  Design  for  Test  Capability 

0  Testing  of  parallel  or  concurrent  programs 

0  Common  Soldier  Machine  Interface 

0  l'o  I  I  a'  A  va  '  I  ab  I  I  '  t  y 

0  A'TCCS  '  ntp'  face 


Figure  3-2.  Risk  Concerns 

3  3  2  t'aining  and  Doctrine  Corrmancl  (TRADOC)  -  TRADOC  is  the  I  omt'at 
CeveoDe'  'CD),  User  Representative.  Trainer,  and  oroponent  for  the  Afv 
Airogram  tradOL  is  responsible  for  preparing  and  updating  the  Operatioria' 
and  Organisational  fC&O)  E  an  and  the  Required  Operational  Capabiiif, 
I  °U'  I  ‘or  t  ne  AFV  Rr  ogn  afn  j  T  RAQOC  designated  representaiicr  wii 

ccrtriua’  V  coordirate  a-d  validate  AFv  reaui'  emen  ts  with  the  AFvTi-,  wi 
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AFV  COMPUTER  RESOURCE  INTEGRATION 
Exper  t ise/T ecbno I oqy 

C3  Testbed,  Lessons  Learned 

Material  Acquisition  and  Management 

Life  Cycle  Management-Fire  i  Weapon  Control,  NBC 

Material  Development,  Acquisition  Analysis,  and  Developmert 

Eva  I uat i on 

Fire  Contr  o I  ,  MAPS 

Automated/Embedded  Training 

Automation,  communication,  and  engineering  research 
Avionics  Technology  Sharing  Program 
VNAS,  LHX  coordination  &  technology  sharing 
Engineer.  PoiAier  Generation 

User  requirement  integration,  C3 I  expertise 

Materiel  integration 

Training 

ACCS,  Army  C4 ,  TMDE ,  POS/NAV,  B2C2 
NBC  Protective  System 
Army  VhSIC,  Microelectronics,  Displays 
Digital  Terrain  and  Mapping 

human  Factors,  Standard  So  I d i er /Mach i ne  interface 

ArtifiC'ai  Intelligence  Technology 

Medical  System  Plans  and  Requirements 

Threat  Analysis,  ADP  Security 

VISTA.  Tech  Base  Support,  Target  Recognition 

Log i St i cs  Suppor  t 

FA ADC 2  I  Developers 

Operational  Testing  of  AFV 

CD/MD  Communications  Expertise 

Human  Factors  Concepts  and  Doctrine 

Vetronics,  Vehicle  Defense,  Automotive  Interface.  VCDS 
Ope’-aTional  Testing  of  AFV  Automation/Communication 
Developmental  Testing  AFV  Automat  i  on/Coirmun  i  cat  i  ons 
Functional  Analysis  Support 

CD,  User  Expert,  Special  Mission  Area  Expertise.  User 
Representative,  Trainer 

Vehicle  Environment  Control  (NBC  Temperature  Control  &  Fire 
E  X  t I ngu I sh I ng ) 

Standard  Multicommand  Management  Information  Systems 
MS  and  Logistic  Support  Planning 


F igure  3-3 
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provide  user  input,  review  the  ACRMP,  and  will  support  the  Director  in  t  r.f 
acquisition,  test,  and  deployment  of  the  AFV.  TRADOC  subordinate  commarui  , 
are  'dentified  in  follow  on  paragraphs.  General  responsibilities  inc^une 
bu!  are  not  i imited  tO' 

A  normal  definition  of  the  AFV  Battalion  and  Below  Command  and 
Cintrol  (B2C2)  and  the  Vehicle  Control  and  Operating  System  IVCOG' 
Hequ I r  emen  t  s 

B  Tailoring  of  plans  and  supporting  documentation  to  ensure  command, 
control,  communications,  and  computer  resource  planning  is  focused 
CP  the  AFV. 

C.  Support  of  the  AFV  Automation  and  Communications  Resources  Wortiriq 
Group  (ACRU/G)  . 

D  Develop  and  refine  user  requirements  for  embedded  training. 

E.  Develop  and  ref  me  commoi-  vehicle  driver  and  corrmandei  wrrit 
s  t  a  t ions. 

F.  Provides  user  perspective  for  AFV  technical  demonstrations  cr 
prototype  tests.  Periodic  reports  may  be  required. 

G  Coordinate  w i t n  materiel  developers  and  maintain  AFV  last  Enrii 

L'lordination. 

3  2  3  Army  Materiel  Command  lAMC)  -  AMC  is  responsible  for  pruvidmu 
Qveral I  computer  resource  acquisition  management  guidance  for  Ariny 
Battlefield  Automated  Systems.  Headquarters  AMC  will  review  the  AGRyP  arid 
wi  I  I  coordinate  the  automation  and  conmun i cat  I  on  resource  and  system 
engineering  activities  for  AFV  and  TRADOC,  and  other  Army  cormands, 
agencies,  and  other  services  as  appropriate.  AMC  will  maintain  all 
tecnn  cal  data  related  to  devel opmen t  and  acquisition  of  the  AFV  and  wii! 
provide  technical  assistance  to  developers,  contractors,  and  users  as 
’•eTji'-ed  AMC  suDordinate  commands  are  identified  in  the  toMowiriq 

pu-ag'-apha  Genpra'  responsibilities  include  but  are  not  iim-ted  to 
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A.  Irtllorlng  of  development  plans  to  support  the  AKV,  Develops  AFV 
hardware  and  software  development  and  test  plans. 

B.  Focus  the  Technology  Base  to  support  AFV  development  and  candidate 
Pre-planned  Product  Improvements  (P3l). 

C.  Manage  AFV  candidate  subsystem  or  components  integration  according 
to  AFV  management  pians.  Provides  cost  estimates. 

0.  Support  ongoing  AFV  Technology  Assessment  (see  Chapter  7,  Plan  for 
Support)  to  include  the  Technology  Base  and  systems  under  Project 
Management  Or gan i 2a t I ons . 

F.  Interface  AMC  products  with  an  AFV  corrmon  vehicle  architecture. 

f  .  Support  the  AFV  Automation  and  Communications  Resources  Working 
Group  (ACRWG)  and  ACRMP  review/update. 

G.  Coordinate  with  combat  developers  and  maintain  AFV  Task  Force 
coord i net i on . 

S.3.4  Combined  Arms  Center  (CAC)  -  CAC,  the  integration  center,  is 
responsible  for  providing  concepts,  doctrine,  and  operational  environment 
guidance  for  the  development  and  maintenance  of  the  AFV  command,  control 
(C2),  commun i cat i on  and  computer  resources  supporting  the  fighting  vehicle 
Uinctions,  and  C2  system  tasks. 

J  4,1  US  Army  Combined  Arms  Combat  Development  Activity  (CACDA)  -  CACDA 
is  responsible  for  system  integration  in  close  coordination  with  CAC  and 
the  Task  Force.  CACDA  serves  as  the  lead  user  proponent  and  will  define 
the  AFV  C3 I  Architecture  of  B2C2  and  VCOS. 

3  3.5  Logistics  Center  (LOGCEN)  -  The  Logistics  Center  is  responsible  for 
til’  providing  concepts,  doctrine,  and  operational  en/ironment  guidance  for 
'■h.  development  and  maintenance  of  AFV  computer  resources  impacted  by 
'ill  I  support  of  the  AFV.  LOGCEN  will  serve  as  the  focal  point  for  the 
"ih'  Service  Support  Control  Systems  (CSSCS) .  LOGCEN  will  review  AFV 
A’  hitecturp  developments  to  ensure  interface  with  the  CSSCS  is 
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3.3.6  Soldier  Support  Center  (SSC)  -  SCC  develops,  reviews,  evaluatL-^, 
and  conducts  appropriate  human  factor  concepts  and  doctrine.  Integratn.i' 
Center  with  TRADOC  schools,  training  activities,  and  other  I ntegrat  ' n-i 
centers  for  AFV  automation  and  communication  human  factors  analysis. 

3.3.7  Communication  and  Electronics  Conmand  (CECQM)  -  CECOM  serves  as  the 
focal  point  for  AFV  conmun i cat i ons ,  electronic  equipment,  and  Army  Command 
and  Control  System  (ACCS)  development,  acquisition,  and  fielding  support 
CECOM  will  ensure  Army  Tactical  Command  and  Control  System  (ATCCSi 
interface  with  AFV  required  Battalion  and  Below  Cormand  and  Control  (B2C21 

system.  CECOM  will  develop  B2C2  and  support  ArV  VETRONICS  Architecture 

i 

integration.  CECOM'  will  act  as  a  lead  agency  for  Contnand .  Control, 
Corrmun  I  cat  i  on  (C3)  and  Intelligence  Electronic  K/arfare  (  I  EW)  . 

3.3.8  Tank  and  Automotive  Command  (TACOM)  -  TACOM  is  responsible  for  the 
AFV  study  contracts,  automotive  equipment,  and  an  AFV  corrmon  vehicle 
electronic  architecture,  supported  by  an  AFV  required  Vehicle  Control  ana 
Operating  System  (VCOS) .  TACOM  will  serve  as  the  VCOS  developer  and  lead 
agency.  Extensive  coordination  with  the  Battalion  &  Below  Command  and 
Control  (B2C2)  developers  and  the  Task  Force  is  expected. 

3.3.9  Armament.  Munitions,  and  Chemical  Command  (AMCCOM)  -  AMCCOM  perform 
overall  life  cycle  management  for  AFV  fire  and  weapon  control,  Nuclear, 
Biological,  Chemical  (NBC)  protection  systems. 

3 . 3 . 9 . 1  Armament  Research  Development  Engineering  Center  (.ARDEC) .  -  ARDEC 
will  serve  as  the  AFV  focal  point  for  AFV  fire  and  weapons  control. 

3.39.2  Chemical  Research  and  Development  Engineering  Center  (CRDEC )  - 
CROEC  will  serve  as  the  AFV  focal  point  for  NBC  protection  system. 
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8.3  10  Missile  Command  (Ml COM)  -  MICOM  is  responsible  for  special  mission 
packages  for  designated  AFV  subsystems.  Coordination  between  CECOM  and 
AFVTF  regarding  the  Forward  Area  Air  Defense  Command,  ''ontrol  i 
Intelligence  {FAADC2I)  system  development  and  integration  required. 

3  8.11  Troop  Support  Command  (TROSCOM)  -  TROSCOM  will  work  in  concert 
with  AMCCOM  for  development  support  of  the  AFV  environment  control  system 
(NBC  protection,  fire  extinguishing,  and  temperature  control). 

8.8, 12  Be  I  voir  Research  Development  Engineering  Center  (BRDEC)  -  BRDEC  i s 
responsible  for  development  and  support  of  the  resupply  manipulator 
technology  for  the  AFV. 


3.3,13  Laboratory  Command  (LABCOM)  -  LABCOM  is  responsible  tor  monitoring 
Ai my  technology  base  for  the  AFV  program  and  reports  finding  to  the  Task 
i or ue  Serves  the  point  of  contact  for  the  AMC/AFVTF  Technology 
Assessment  refinements.  CECOM  coordination  is  required. 

8  3,13,1  Fluman  Engineer  Laboratory  (FiEL)  -  FIEL  conducts  human  factors 
uua I  i  tat  i  ve ,  and  quantitative  analysis  for  AFV.  Primary  advisor  to  combat 
development  and  materiel  development  corrmunities  on  human  factor  issues. 
As  file  chair  of  the  AMC/TRADOC  Robotics  Task  Base  Group  (RTBG) ,  HEL  wi i I 
monitor  RTBG  membership  projects  for  AFV  applications. 


8.3,13.2.  Flarry  Diamond  Laboratory  (HDD  -  FIDL  is  responsible  for  robotics 
and  artificial  intelligence  systems  support  related  to  the  AFV.  The 
AM'  /TRADOC  Artificial  Intelligence  (AI)  Tech  Base  Group  (AITBG),  chaired 
t’V  HDL  will  review  and  monitor  the  DA/DCD  AI  Technology  Base  for  AFV 
applications.  Findings  will  be  reported  and  updated.  HDL  wl I  I  provide 
I ‘I  iirrmendat  i  ons  for  selected  portions  of  the  Technology  Assessment.  HDL 
wi'l  assume  the  AFV  lead  In  Target  Acquisition,  Combat  Identification, 
directed  energy  (DE)  and  electro-magnetic  pulse  (EMP)  protection. 
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3.3.13.3  US  Army  Electronic  Technology  &  Devices  Lab  (ETDL)  -  F TDl  I g 
responsible  for  development  and  acquisition  of  the  microelectronics  anJ 
displays  for  the  AFV. 


3.3.14  Test  and  Evaluation  Command  (TECOM)  -  TECOM  is  responsible  for  all 
government  developmental  testing  for  the  AFV  communication  and  automation 
system.  Responsible  Include  test  planning,  the  conduct  of  testing, 
specification  analysis,  and  result  reporting.  Scope  of  testing  includes 
AFV  subsystem  compact  through  the  entire  vehicle  electronic  architecture. 

3.3.15  Operational  Test  and  Evaluation  Agency  (OTEA)  -  OTEA  is 
responsible  for  continuous  and  comprehensive  evaluation  which  includes 
operational  testing  of  the  AFV.  OTEA  will  support  the  AFVTI  by 
participating  In  the  planning  and  developing  of  all  operational  testing 
required  to  test  the  AFV  in  an  operational  environment. 

3.3.16  US  Army  Loflistics  Evaluation  Agency  (USALEA)  -  USALEA  will  provide 
assistance  to  the  AFVTF  in  developing  logistic  support  planning  and  will 
participate  in  the  review  of  developmental  efforts  for  logistical 
implications  and  adequacy  of  Integrated  Logistic  Support  (ILS)  planning. 

3.3.17  US  Army  Development  and  Employment  Agency  (ADEA) .  -  ADEA  is 
responsible  for  command,  control,  and  communications  (C3)  testing  and 
development.  Coordinates  with  the  Task  Force  for  lessons  learned  and 
ongoing  test  results. 

3  3.18  US.  Army  Materiel  Systems  Analysis  Activity  (AMSAA)  -  Reviews  the 
AFV  materiel  development  and  acquisition  processes  for  vehicle  electronir 
and  computer  resources.  Serves  as  the  independent  evalu.ator 
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3  3.19  TRAOOC  Analysis  Command  (TRAC)  -  TRAC  is  responsible  for  providing 
functional  analysis  support  for  the  AFV  program.  Performs  analyses, 

studies,  and  evaluations  of  AFV  automation  and  communication 

requirements.  Provide  technical  assistance  In  test  planning,  requirement 
definition  refinements,  and  design  reviews. 

3  3  20  TRAPOC  Combined  Arms  Test  Activity  (TCATA)  -  TCATA  In  coordination 
with  CAC  and  the  Task  Force  will  plan,  execute,  and  report  on  operational 
tests  for  the  purpose  of  determining  AFV  automation  and  communication 
effect!  veness . 

3.3.21  TRAPOC  Service  Schools  -  General  responsibilities  include  but  are 
not  I imi ted  to : 

A.  Develop  or  refine  Battalion  and  Below  Command  and  Control  (B2C2) 
and  Vehicle  Control  and  Operating  System  (VCOS)  requirements  in 
coordination  with  the  Task  Force  and  TRAPOC  proponent. 

R  Develop  plans  and  specifications  for  mission  specific  expert  or 

decision  support  systems  for  initial  AFV  fielding  or  as  P3I 
cand I  dates. 

C.  Monitor  AFV  materiel  development  activities  and  plans  to  ensure 
school  or  center  mission  area  requirements  are  properly  accounted 
for  and  implemented. 

D.  Develop  and  refine  mission  unique  embedded  training  requirements. 

E.  ACRIWG  support  and  ACRMP  review. 

3  3.21  1  Air  Defense  School  -  Serve  as  Forward  Area  Air  Defense  Command 
Control  Intelligence  (FAADC2I)  user/expert.  Develop  Battalion  and  Below 
Cnmmand  and  Control  (B2C2)  system  direct  and  automatic  interface. 

3  3  21  2  Armor  School  -  Share  Battlefield  Management  System  (BVS) 
e-[frtisc'  Continue  BMS  development  for  fielding  as  the  optimal  AFV  P3 1 
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Battalion  C2  system,  (the  AFV  B2C2  system  is  the  target  Battalion  l.> 
system  for  fielding).  Coordinate  KKith  the  Vehicle  Control  and  Operatin,; 
System  (VCOS)  materiel  developer  (hardware/software) . 

3.3.21.3  Chemical  School  -  Serve  as  the  AFV  Environmental  Control  System 
user  expert. 

3.3.21.4  Engineer  School  -  Develops  engineer  computer  related  resource 
requirements.  Serve  as  the  AFV  traf f i cab  I  I  I ty  and  terrain  analysis  user 
expert . 

3.3.21.6  Field  Artillery  School  -  Serve  as  Advanced  Field  Artillery 
Tactical  Data  System  (AFATDS)  user/expert.  Develop  B2C2  system  direct 
interface  at  the  Battalion  and  Company  levels.  Lead  coordination  with  the 
Air  Defense  and  Infantry  Schools  and  Centers  regarding  fire  control 
automation  and  communications  matters.  Coordinate  with  the  VCOS  materiel 
deve I oper . 

3.3.21.6  Infantry  School  -  Coordinate  with  the  VCOS  materiel  developer. 
Ensure  the  VCOS  is  capable  of  supporting  Infantry  requirements. 

3.3.21.7  Intelligence  Center  and  School  -  Serve  as  the  All  Source 
Analysis  System  (ASAS)  user/expert.  Develop  plans  for  direct  B2C2 
interface. 

3.3.21.8  Missile  and  Munition  Center  and  School  -  Serve  as  the  AFV  user 
representative  for  munitions.  Coordinates  with  fire  control  combat  arid 
materiel  developers,  as  required.  Ensure  annmunition  is  capable  for  use 
with  AFV  autoloaders  and  robotic  like  manipulators. 

3.3.21.9  Military  Police  School  -  To  be  determined  (TBD) . 
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:r3.21  10  Ordnance  Center  and  School  -  Serve  as  user/expert  tor  AFV 

diiignostlcs  and  prognostics.  Support  AFV  Automated  Logbook  development. 

J. 3. 21. 11  Quartermaster  School  -  Serve  as  user  expert  for  AFV  refuel, 

ri'arm,  and  resupply  robotic  manipulators.  Maintc'ln  close  coordination 
wi  th  LOGCEN. 


3.3.21.12  Signal  Center  -  Serve  as  combat  Information,  voice,  and  data 
corrmun  I  cat  I  ons  expert.  Conduct  cotnnun  i  cat  I  ons  traffic  studies  to  support 
AFV  B2C2  and  VCOS  systems. 

3.3  21.13  Transportation  School  -  TBD. 

3.3.21.14  Aviation  School  -  Monitor  AFV  development  requirements  to 
iMisure  ground-to-air  and  air-ground  communications  are  planned  for  and 
effected  within  the  AFV  C3 1  Architecture. 

3  3  21.15  JFK  Special  Warfare  Center  -  Review  AFV  automation  and 
communications  plans  to  ensure  AFV  specifications,  designs,  and  products 
will  not  prohibit  special  operations  in  a  close  combat  heavy  environment. 

3.3.22  Intelligence  and  Security  Command  (INSCOM)  -  INSCOM  is  responsible 
fnr  perforiTiing  a  threat  analysis  of  the  AFV  and  to  provide  advice  and 
guidance  to  the  AFVTF,  ACRWG,  and  Material  Developers  regarding  system 

cecur  i  ty  . 


3  3.23  Information  Systems  Command  (USAISC).  -  Serve  as  the  primary  focal 
point  for  Standard  Mu  I t i command  Management  Information  System  (STAMMIS) 
hardware  and  software.  Provide  necessary  technical  and  managerial  support 
for  potential  future  plans  to  Interface  the  B2C2  system  with  the 
appropriate  STAMMIS,  via  a  common  communication  medium  with  selected 
combat  command  and  control  system(s) . 

y 
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3.3.24  US  Army  Engineer Ing  Topographic  Labs  (ETL)  -  ETL  is  responsible 
for  development  of  electronic  map  representation  and  topographic  tools  for 
AFV.  Will  coordinate  a  data  base  design  and  software  tools  for  AFV 
tactical  use. 

3.3.26  U.S.  Army  Health  Services  Cornmand  (HSC)  -  HSC  Is  responsible  for 
developing  VCOS  medical  embedded  systems.  HSC  will  coordinate  with  the 
designated  TRAOOC  AFV  subsystem  representative  and  develop  user  plans  and 
documents  for  a  tactical  expert  system  for  AFV  ambulance  and  Battalion  Aid 
Station  use. 

3.3.26  Aviation  System  Command  (AVSCOM)  -  Coordinates  an  Avionics 
technology  sharing  program  with  the  AFV  Task  Force.  Expected  participants 
are  the  Avionics  Research  and  Development  and  Applied  Technology  Labs. 

3.3.27  US  Army  Research  Office  (ARO)  -  ARO  is  responsible  for  focusing 
automation,  cottmun  I  cat  i  on ,  and  engineering  research  effort  toward  AfV 
improvement . 

3.3.28  US  Army  Research  Institute  (ARI)  -  AR I  will  assist  in  AFV  training 
support  and  planning.  Will  ensure  automation  support  In  the  forc3  ul 
embecded  training  is  Incorporated  into  training  plans  witfi  planned 
functional  growth. 

3.3.29  System  Integrator  -  The  specific  responsibilities  of  the  AFV 
System  Integrator  (PEO  or  Task  Force  contractor  for  System 
Engineering/Technical  Assistance)  will  continue  to  be  refined  during  the 
AFV  materiel  acquisition  process.  Anticipated  responsibilities  include: 

A.  Planning  and  Implementing  the  design,  development,  and  production 
of  the  AFV  in  accordance  with  the  AFV  requirement  and  contractual 
base  line. 
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B  Direct  and  control  the  efforts  of  the  ACRWG  Integration  Team  for 
the  Integration  and  test  of  AFV  computer  resources. 

C.  Conduct  design  reviews  in  accordance  with  the  contractual 
baseline,  development  schedule,  and  good  engineering  practices. 

D.  Establish  and  execute  an  independent  quality  assurance  program  for 
the  contract. 

E.  Ensure  that  necessary  communication  and  computer  resource 
documentation  is  produced,  maintained,  and  controiled  during  the 
development  and  production  phases  of  the  contract. 

F.  Ensure  that  all  deliverables  specified  In  the  Contract  Data 
Requirements  List  (CORD  for  the  computer  resources  are  produced 
and  delivered  in  accordance  with  the  program  schedule  and 
contractual  baseline. 

(j  Provide  support  for  the  resource  Items  as  specified  in  the 

contr ac  t . 

FI,  Ensure  VETRONICS  interface  and  integration. 

I.  Ensure  command  and  control  suppor tab i I  I ty . 

J.  Coordinate  the  acceptance  testing  and  maintenance  of  any 
commercial  computer  resource  I  terns  for  Integration  with  contractor 
('eve  I  oped  software. 

Until  a  System  Integrator  is  designated,  these  functions  will  be 

accomplished  by  the  Automation  and  Communication  Resource  Working  Group 
(ACRWG) . 


3.3.30  AFV  Workinp  Groups  and  Boards  -  AFV  working  groups  and  boards  will 
support  the  AFVTF  with  top  level  guidance,  advice,  and  technical  expertise 
in  specif  Mzed  areas. 


3  .3  30  1  AFV  Retired  Board  of  Governors  -  The  Retired  Board  of  Governors 
will  periodically  review  AFVTF  programs  and  progress  and  will  make 
r pcommendat I ons  to  the  Task  Force  pertinent  to  the  AFV  program. 
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3.3.30.2  Removed  -  reserved  for  future  use. 

3.3.30.3  Automation  and  Communications  Resources  Working  Group  ( ACRWG I 
The  ACRWG  Mill  act  for  the  AFVTF  on  those  matters  pertaining  tu  ttic 
development  and  fielding  of  automation  and  comrvun I  cat  ions  resources  for 
the  AFV.  The  ACRWG  Mill  operate  supporting  boards  and  committees  and  miM 
maintain  this  ACRMP.  RevleM  the  ACRWG  Charter  at  Appendix  C. 


3.3.30.4  AFV  Teat  Integration  Working  Group  -  The  Test  I  ntegr  h  t  i  ">0 
Working  Group  (TIWG)  Mill  act  for  the  AFVTF  on  all  matters  involvin.'j 
testing  of  the  AFV  or  its  components.  The  TIWG  Mill  support  the  Test  dnd 
Evaluation  Master  Plan  (TEMP)  development  and  revieM  the  ACRMP  for 
specific  automation  and  communication  resource  testing  Issues. 


3.3.30.5  AFV  Maneuver  Working  Grout 


assist  in  the  AFV  automation 


and  communication  requirement  development.  RevieMS  AFV  requirements 
documents  to  ensure  integrated  Command,  Control,  Communication, 
Intelligence  are  properly  addressed  and  provides  recommendations  to 
improve  the  ACRMP. 

3.3.30.6  AFV  MANPRINT  Working  Group  -  The  MANPRINT  Working  Group  revieMS, 
develops,  and  resolves  AFV  human  factors  issues.  The  family  common 
so  I d I er /mach I ne  Interface  Is  of  primary  concern.  This  group  Mill  review 
the  ACRMP  to  ensure  human  factors  engineering  is  properly  planned. 

3.3.30.7  AFV  Logistics  Management  Working  Group  -  Th®  logistics  Group  is 
primarily  responsible  for  assisting  in  AFV  Logistic  Management  and 
Acquisition  Strategies.  This  group  Mill  revieM  the  Integrated  Logistics. 
Support  Plan  ( I LSP)  and  ACRMP  to  ensure  consistency. 

3.3.30.0  AFV  Analysis  and  Simulation  Working  Group  -  This  group  s 
responsible  for  developing  supporting  analysis  and  simulation  (or 
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modeling)  effort  for  the  AFV  concept  formulation  process  leading  toward  an 
AFV  required  operational  capabilities  (ROC)  document.  This  group  will 
insure  C3I  requirements  are  incorporated  in  the  analytical  efforts 

J  3  30  3  AFV _ Training  Development  Working  Group  -  Training  requirements 

■ind  development  efforts  will  be  initiated  and  monitored  by  this  group. 

3  3  31  Government  Management  and  Working  Groups  -  Applicable  Government 
management  and  working  groups  will  participate  in  the  developrment  of  the 
AFV  and  will  ensure  that  related  system  developments  conform  to  the  AFV 
program 

3  3  31.1  General  Officer  Steering  Conrmittees  (GOSC)  -  Selected  GOSC ’ s 
will  provide  guidance  on  the  direction  and  integration  of  related  systems 
clfve  I  npment . 

3  3,31,2  Standard  Army  VETRONICS  Architecture  (SAVA)  Management  Steering 
Cnrrm  i  t  tee  -  The  SAVA  steering  committee  will  be  responsible  for  providing 
guidance  and  direction  to  the  VETRONICS  developers  In  support  of  AFV.  The 
SAVA  committee  will  closely  coordinate  with  the  Task  Force. 

33.31 .3  Army  Command  and  Control  System,  Life  Cycle  Software  Engineering 
■  The  ACCS  Life  Cycle  Support  Centers  (or  centers  for  Life  Cycle 
tngineering)  will  provide  data  and  assistance  to  ensure  that  the  AFV 
interfaces  correctly  with  external  battle  control  automated  functions. 
Reviews  ACRMP  for  content  accuracy  and  provides  recommendation  for 
ducurnent  Improvement. 
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3  3  31.4  Robotics  Tech  Base  Group  (RTBG)  -  The  AMC/TRADOC  Hoboi  i  ^ 

Technology  Base  Group,  chaired  by  HEL  Mill  identify  robotics  terlirnj'i 
and  assist  in  requirements  development  for  AFV.  The  RTBG  will  review  tn- 
ACRWP  to  ensure  robotic  developments  are  properly  managed  withiri  the  At'; 
pr  oy r  am . 

3.3.31.5  Artificial  Intelligence  Tech  Base  Group  (AITBG)  -  The  AMC/TBADU' 
Artificial  Intelligence  (Al)  Technology  Base  Group,  chaired  by  lABCOM 
iHOL)  will  assist  in  requirements  development  and  Al  technology 
applications  for  AFV.  The  AITBG  will  review  the  ACRMP  for  Al  technira; 
management  technique  completeness. 

3.3.31 .6  Other  Working  Groups.  Committees  and  Management  8o<^  ds 
Numerous  working  groups,  committees,  and  management  boardu  exist 
throughout  the  Army.  These  groups  are  required  to  review  their  missiuri  m 
charter  for  AFV  applicability  and  report  their  findings  to  the  Ai V  lask 
Force . 

3.3.32  Army  Program  Executive  Of f Icers/Proqrams  (PEO)  -  It  is  anticipated 
that  PEO  and  associated  Project  Management  (PM)  organizations  will  play  a 
vital  role  in  AFV  development.  The  Technology  Assessment  (first 
pubi  ished,  Feb  87  and  provided  to  AMC)  determined  a  myriad  of  automation 
and  cormtun i cat  I  on  systems  under  PEO  development,  at  or  near  fielding  or 
undergoing  preplanned  product  improvements  are  applicable  to  AFV.  Many 
have  direct  application  or  interface  witn  the  AFV  program.  The  Task  Force 
goal  Is  to  maximize  Integration.  Figure  3-B  lists  the  candidate 
applicable  offices.  General  PM  or  PO  integration  responsibilities  include 
but  are  no  ■:  limited  to: 

A.  TRALIOC  System  Manager  coordination  in  AFV  matters. 
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B  Provide  AFV  Task  Force  system,  subsystem  or  component  milestone 

i nf  ormat i on 

f  Furnish  results  of  technical  demonstrations  and  other  test  in 

support  of  the  AFV  Concept  Exploration  and  Demonstration  Validation 
Phase 

0  Update  PM  or  Project  Office  (PO)  plans  to  support  AFV  schedules. 
Recormends  AFV  milestone  changes  or  Improvements. 

F.  Review  AFV  program  management  documentation  to  include  the  ACRMP 
for  completeness 

F  Support  the  Task  Force  ongoing  Technology  Assessment  efforts. 

Identify  critical  issues  and  preplanned  product  Improvements  (P3t), 

G  Update  communication  and  automated  system,  resource  management 
plans  to  ensure  planning  interface  with  AFV. 

H.  Provide  technical  assistance  to  the  Automation  and  Communication 
Resource  Working  Group  (ACRWG) . 

I.  Provide  technical  data  and  specification  concerning:  siire, 

weight,  power,  and  operational  considerations  for  tactical  vehicle 
I n  tegr  ation  efforts. 

J.  Define  current  system,  current  and  projected  capability  to 

interface,  and  interconnect  with  a  vehicle  or  chassis  common  data, 
power,  voice  or  video  bus  architecture. 

K.  Share  lessons  learned  in  support  of  AFV  cost  avoidance  efforts. 

till  or  gan  i  za  r  I  ons  wfiich  are  applicable  to  AFV  follow  (detail  are  to  be 
ii>fined  m  future  updates).  Figure  3-A  denotes  project  managemer t 
TT  o.in I za t I ons  (PMO)  which  have  probable  application.  PEG  and  PMO 


I  ■■'.I',  ns  I  b  I  I  I  :  i  es  ,  in  general,  will  be  refined  in  subsequent  ACRMP  updates. 
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0  HAWK 

o  PATRIOT 

o  STINGER 

o  AMMUNITION  LOG 'ST  ICS  (AMMOLOG) 

o  boresight  devices 

o  CLOTHING  AND  INDIVIDUAL  EQUIPMENT 
o  BRADLEY  FIGHTING  VEHICLE  SYSTEMS 
o  M9  ARMORED  COMBAT  EARTHMOVER  (ACE) 
o  Mil  3  FAMILY  OF  VEHICLES 

o  MINES,  COUNTERMINES  AND  DEMOLITIONS 

o  MOBILE  ELECTRIC  POWER  (MEP) 

o  MORTAR  SYSTEMS  (PROVISIONAL) 

o  MULTIPLE  LAUNCH  ROCKET  SYSTEM  (MLRS) 

Q  NIGHT  VISION  DEVICES 

o  SATELLITE  COMMUNICATIONS 

o  SMOKE/OBSCURANTS 

o  TACTICAL  AIRBORNE  REMOTELY  PILOTED  VEHICLE/DRONE  SYSTEM  (RPV) 

0  COMMERCIAL  CONSTRUCTION  EQUIPMENT  AND  SELECTED  MATERIALS  HANDLING 
EQUIPMENT  (CCE/SMHE) 

0  TANK  SYSTEMS 

0  Ml  ABRAMS  TANK  SYSTEM 

0  TANK  MAIN  ARMAMENT  SYSTEMS  (TMAS) 

0  M1A1  ABRAMS  TANK 

Q  M60  TANKS 

o  TEST,  MEASUREMENT  AND  DIAGNOSTIC  EQUIPMENT  (TMDE) 
o  TOPOGRAPHIC  SUPPORT  SYSTEMS 

o  TRAINING  DEVICES  (TRADE) 

o  ARMOR  TRAINING  DEVICES  (ARD) 

o  ARMY  COMMUNICATIVE  SYSTEMS 

o  NUCLEAR,  BIOLOGICAL,  CHEMICAL  (NBC)  PROTECTION  FOR  COMBAT  VEHICLES 
AND  CREWS 

Project  Management  Organisations 
Figure  3-4 


3.3.32.1  PEO  Command  and  Control  Systems  (CCS)  -  PEO  CCS  desionaie' 

member  to  the  AFV  Automation  and  CotHnun  I  cat  i  on  Resource  Work.r'u  !■ 
(ACRWG)  .  Integrates  the  AFV  Battalion  ar>d  Be  I  oi*(  Cormiand 
(B2C2)  Into  the  Army  Tactical  Corrmand  ard  Control  System 
under  program  managers  (PM)  listed  in  .he  figure  t>e  .'i*  •  • 

applicability  to  AFV  C3 I  Architecture  deve I opmenT 


Id-aim  9J4 


UNCLASSIFIED  tt  SEP  D? 


AAAOAED  FANILV  OF  VEHICLES  <AFV>  AUTOMATION  AND 
COHNUNICATION  AESOUACE  HA. .  <U>  AAHOAED  FAMILV  OF 
VEHICLES  TASK  FOACE  FOAT  EUSTIS  VA  A  D  DUCKSTAD 
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OPERATIONAL  TACTICAL  DATA  SYSTEMS  (OPTADS) 

ADVANCE  FIELD  ARTILLERY  TACTICAL  DATA  SYSTEM  (AFATDS) 
COMBAT  SERVICE  SUPPORT  CONTROL  SYSTEM  (CSSCS) 

FORWARD  AREA  AIR  DEFENSE  COMMAND  CONTROL  (FAADC2) 

JOINT  TACTICAL  FUSION  (JTF)/ALL  SOURCE  ANALYSIS  SYSTEM  lASAS) 
COMMON  HARDWARE /SOFTWARE  SYSTEMS 


PEO  CCS  Program  Managers 
Figure  3-6 


3.T.32.2  PEO  Communications  (PEO  COMM)  -  PEO  COMM  designates  a  member  to 
the  ACRWG.  A  communications  capability  is  a  common  AFV  requirement. 
Three  of  the  five  projects  (MSE,  SINCGARS,  ADDS/PLRS)  have  direct 
applicability  to  AFV.  SATCOM  applicability  is  pending  AFV  requirements 
refinement.  MSCS  Is  applicable  for  Corps  and  above  echelons. 


MOBILE  SUBSCRIBER  EQUIPMENT  (MSE)’ 

SINGLE  CHANNEL  GROUND  &  AIRBORNE  RADIO  SYSTEM  (SINCGARS)’ 
ARMY  DATA  DISTRIBUTION  SYSTEM  (ADDS) /POSIT  ION  LOCATION  REPORTING 

SYSTEM  (PLRS)  ’ 

SATELITE  COMMUNICATIONS  (SATCOM)* 

MULT  I -SERVICE  COMMUNICATIONS  SYSTEMS  (MSCS)* 


'  -  Direct  AppI icabi I i ty 
-  -  Direct  Applicability  to  be  Determined 

PEO  COMM  Program  Managers 
Figure  3-6 


3  3.32.3  PEO  Intelligence  and  Electronic  Warfare  (PEO  I EW)  -  Coordinates 
vgilh  PEO  CCS  and  PEO  COMM  on  AFV  C3 I  Architecture  (B2C2  &  VCOS)  matters. 

I  i<iitrp  3  8  briefly  lists  systems  which  may  have  AFV  d  I  rect  app  I  Icab  1 1  i  ty  . 
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GUARDRA I L 
TRAILBLA2ER 
JSTARS 
QUICKF IX 
REMBASS 


MVD 

FIRE  FINDER 
FAAD  SENSORS 
TACJAM 
TEAMPACK 


PEO  lEW  Program  Managers 
F  Igure  3-7 


3.3.32.4  PEO  Standard  Army  Mu  1 1 icommand  Management  Information  Systems 


(PEO  STAMMIS)  -  As  B2C2  and  ATCCS  matures  it  is  anticipated  that  direct 


inkages  will  be  established  with  Army  STAMMIS  to  reduce  soldier  workloads. 


RETAIL  LOGISTICS  SYSTEMS 
PERSONNEL  SYSTEMS 
MEDICAL  SYSTEMS 
T ACM  IS  (HARDWARE) 


PEO  STAMMIS  Program  Managers 
Figure  3-8 


3.3.32.5  PM  Combat  Identification  Systems  (PM  CIS)  -  PM  CIS  support  of 


AFV  Is  projected  to  include  identification  of  technologies  in  the  areas  of 
target  acquisition  and  evolutionary  or  Incremental  CIS. 


3.3.32.6  thru  3  3.32.15 


Reserved  for  future  use.  The  figure  buluw 


briefly  describes  anticipated  usage. 
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PEO 


PROJECTED  AFV  SUPPORT 


HEALTH  CARE  SYSTEMS 

PM  LHX 

ARMAMENTS 

CLOSE  COMBAT  MISSILES 
FIRE  SUPPORT 
FORWARD  AREA  DEFENSE 

TROOP  SUPPORT 
CHEMICAL 

CLOSE  COMBAT  VEHICLES 


COMBAT  MEDICAL  SYSTEMS. 
TECHNOLOGY . 

ARTILLERY  &  MORTAR  FIRE  CONTROL. 
TOW  FIRE  CONTROL. 

MLRS  &  ATACMS  FIRE  CONTROL. 

RPV  &  UAV  OPERATIONAL  CONTROL, 
FAAD  VEHICLE  CONTROL. 

MOBILE  ELECTRIC  POWER. 

NBC  DEFENSIVE  MEASURES. 
INTEGRATION  AND  TRANSITION. 


PEO  Support  Pending  Coordination 
Figure  3-9 


3.3.33  Department  of  the  Army  or  Special  Project/Syetem  Offices.  It  is 
anticipated  that  responsibilities  will  be  the  same  as  outlined  in 
par  agr  aph  3.3.32. 


3.3.33.1 
pr ejects 


Classified  Programs  -  Offices  concerned  with  highly  classified 
related  to  combat  identification,  tactical  cornnun i cat  ions, 
coTimand  End  control  (C2) ,  artificial  intelligence,  robotics,  and  tactical 
vehicle  electronics  are  responsible  for  maintaining  contact  with  the  Task 
Program  applicability  to  AFV  must  be  determined.  Task  Force 


r  0  r  ('  e  . 


personnel  have  prerequisite  security  clearances. 


3  ,3.33.2  Reserved  Future  Use. 


3  4  AFV  SYSTEM  DEVELOPMENT  PHILOSOPHY  -  The  development  of  automation  and 
corrmun  I  ca  t  i  on  resource  items  will  be  in  accordance  with  the  basic 
r i-qu i rements  of  AFV  in  the  Justification  of  Major  System  New  Start 
(  iWSNj) ,  Operational  and  Organization  Plan  (OiO) .  the  evolving  Required 
Opot  .It lona)  Capability  (ROC),  and  other  appropriate  requirements 
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documents.  The  Mission  Equipment  Package  (MEP)  and  associated  hardware/ 
software  for  the  AFV  will  be  furnished  in  accordance  with  AFV  design  to 
meet  overall  system  architecture  requirements.  Automation  and 
communication  requirements  and  developments  will  be  treated  as  an  integral 
part  of  the  AFV  life  cycle. 


3.5  STAFFING  REQUIREMENTS  -  The  AFV  system  Integrator  (pending  or  TBD) , 
contractors,  and  supporting  government  agencies  will  provide  the  necessary 
staff  for  requirements  development,  analysis,  design,  development,  test, 
maintenance,  and  support  of  the  computer  resources  during  the  AFV  Life 
Cycle.  Verification  and  validation  of  the  operational  computer  resources 
will  be  performed  by  the  system  Integrator  and  the  government. 
Independent  verification  and  validation  will  be  performed  by  the 
government  or  designated  government  agent  independent  of,  and  not 
affiliated  with,  the  contractor  developing  the  AFV  computer  resources. 

3.6  INTEGRATION  RESPONSIBILITY  -  The  Director,  AFVTF  has  overall 
responsibility  for  managing  the  Integration  of  the  automation  and 
communication  resources  into  the  operational  system  environment.  Tiie 
ACRWG  will  be  the  Director’s  action  team  (Figure  3-2).  CECOM  is  the 
planned  lead  C4  integrator  and  TACOM  is  the  VCOS  integrator.  CACDA  will 
integrate  C4  and  vehicle  control  combat  development  requirements.  All 
lead  AFV  integrating  centers  will  establish  program  management  controls. 

3.7  DEVELOPMENT  OBJECTIVES  -  Definition  of  requirements,  development 
approach,  audits,  testing,  and  maintenance  of  newly  developed  arid 
modification  efforts  for  communication  and  computer  resources  will  be 
accomplished  according  to  the  objectives  outlined  below.  During  the 
accomplishment  of  these  objectives.  It  will  be  necessary  to  identify  the 
extent  to  which  existing  systems  and  equipments  and  process  concepts  will 
be  used.  An  evaluation  of  the  systems  capacity  for  growth  is  also 
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required.  Additionally,  identification  of  projected  computer  equipment 
and  computer  program  development  costs,  Including  the  the  appropriate  work 
breakdown  structures,  will  be  necessary.  The  sources  of  this  Information 
will  be  the  Request  for  Proposal  (RFP) ,  specifications,  and  other 
development  program  documents.  As  these  documents  evolve,  specific 
Information  will  be  extracted  and  Included  in  the  ACRMP  during  subsequent 
updates.  Detailed  Implementation  of  the  objectives  are  contained  in  the 
Chapters  which  follow. 

a  7.1  Requirements  Definition  -  The  requirements  of  the  system  wi I  I  be 
defined  in  the  AFV  Requirements  Document.  These  requirements  will  be 
reflected  in  appropriate  Development  and  Product  Specifications  and  the 
lest  Procedures.  The  developers  (contractor  or  government)  will  maintain 
traceability  of  the  requirements  throughout  the  design  phases  of  AFV. 
I'evelopers  must  utilize  approved  Requirements  Engineering  Methodology  tied 
to  a  work  breakdown  structure  to  demonstrate  the  trail  of  a  requirement 
from  the  System  Specification  to  a  specific  test  result. 

3.  7.  1.1  Concept  Exploration  Phase  -  AFV  requirements  will  be  fully 
defined  curing  concept  exploration.  The  approved  (June  ’87)  Operational 
and  Organizational  (O&O)  Plan  and  evolving  Required  Operational 
rapabillties  (ROC)  directly  and  indirectly  require  a  myriad  of  automation 
and  communication  system  resources  to  support  AFV  operations.  Although 
concept  exploration  may  be  seen  as  a  combat  developer  lead  action,  cost 
effective  Integration  requires  a  combat  and  materiel  developer  team. 
Therefore  TRADOC  and  AMC  will  be  Involved  In  the  concept  formulation 
pr  ocess . 

7  1.2  Demonstration  and  Validation  -  Requirements  will  be  refined 
during  this  phase.  Details  are  to  be  provided  during  a  subsequent  ACRMP 
update . 
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3. 7,  1.3  Full  Scale  Deve I opit>ent  -  Paragraph  Is  to  be  developed. 

3. 7. I. 4  Production  and  Deployment  -  User  requirements  updates  will  be 
handled  through  life  cycle  activities.  Further  details  are  to  be  provided 
at  a  later  date. 


3  7.2 


Ph 1 1 osoDhs 


The  development  of  computer  resour 


software,  which  includes;  analysis,  design,  coding,  fabrication,  and  unit 
testing.  Integration  testing.  Software  Configuration  I  tern  (SCI)  testing, 
system  integration  and  testing,  and  operational  testing  and  evaluation, 
Hardware  Configuration  Item  (HCI)  testing,  will  follow  the  pr ocertur i>., 
outlined  in  the  (to  be  developed)  Hardware  and  Software  Development  Plan 
(HiSOP) .  Resource  development  will  use  the  top  down  design  approach  ao 
stated  in  DOO-STO-2167 .  Development  support  documentation  will  be 
maintained  by  the  system  Integrator  In  accordance  with  the  same  standard 
(DOD-STD-2167)  and  will  be  provided  to  the  AFV  Director  for  review  and 
comment  during  all  developmental  phases.  The  AFV  Director  will  monitor 
software  development  effort  during  Demonstration  and  Validation  and  follow 
on  phases  by  the  means  of  Informal  end  formal  technical  reviews.  During 
Production  the  AFVTF  will  monitor  and  control  the  development  effort  by 
using  formal  reviews,  audits,  and  data  deliverables  as  set  forth  in  the 
production  contract. 

3.7.3  Audits  and  Controls  -  Informal  and  formal  reviews  may  be  specified 
and  used  by  the  government  for  management  of  hardware  and  software 
development.  Informal  and  formal  reviews  are  discussed  in  Chapter  6  3.2 
and  descriptions  of  these  reviews  are  included  at  Appendix  I. 


3.7.4  Teat  and  Evaluation  -  The  testing  of  computer  resources  will  follow 
the  procedures  outlined  in  the  Test  and  Evaluation  Master  Plan  (TEMP)  and 
supporting  test  documentation.  A  TIWG  Is  established  to  coordinate 
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government  end  contractor  test  activities  to  assure  that  Development  and 
Operational  Test  and  Evaluation  of  the  system  is  successfully 
accomplished.  Refer  to  Chapter  6,  Test  and  Evaluation. 

375  AFV  Hardware  and  Software  Maintenance  -  The  AFV  hardware  (to 
include  communications)  and  software  reconfiguration  for  systems  prior  to 
fielding  (pre-deployment),  during  deployment  and  Post  deployment  are 
discussed  in  Chapter  Seven,  Plan  for  Support. 

3  8  STANDARDIZATION  AND  PROVEN  APPROACH 

3.8  1  Software  Standard izat ion  -  AFV  design  planning  stresses  a  modular 
and  multimission  capability  hardware  and  software  approach.  The  software 
development  effort  will  use  the  Ada  High  Order  Language  (HOD  in 
accordance  with  OOD  Instruction  6000.31.  Exceptions  If  required  must  be 
approved  and  will  be  based  on  performance,  testability,  maintainability, 
and  program  management  Improvement.  Request  for  waivers  will  be  processed 
thru  respective  chains  of  command  and  must  be  in  compliance  with 
DODD-3405.2 

3.0.2  Communication  Standardization  -  To  be  determined  based  on  CECOM 
r  ecorrmendat  I  ons  . 

3  8.3  Computer  Hardware  Standardization  -  To  be  determined. 

3.9  DEVELOPMENT  SUPPORT  REQUIREMENTS 

3  9. I  Software  Support  Facilities  -  After  concept  exploration,  the  system 
integrator  will  facilitate  the  development  of  the  Life  Cycle  Engineering 
Center  (LCEC)  for  the  AFVTF .  The  software,  firmware,  and  microcode 
developers  will  utilize  an  integrated  software  development  station  for  the 
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development  of  ail  AFV  required  application  software  developed 
Coordination  between  the  AFV  software  support  facilities  and  the  LCEC  is 
critical  to  ensure  adequate  post-deployment  software  support.  During 
future  update  cycles,  the  ACRMP  will  be  expanded  to  Identify  specific  AFV 
software  support  facility  requirements  as  they  are  Identified  and 
defined.  LCEC  Implementation  plans  must  be  finalized  before  Milestone 
III.  It  is  ant ic i pa ted  that  there  will  be  at  least  two  LCEC’s,  In  direct 
support  of  AFV,  one  for  B2C2  and  one  for  the  VCOC .  If  hardware  support  is 
separated  from  hardware,  then  software  developers  will  have  hardware 


experienced  staff. 


3.9.2  Computer  Hardware  Support  Facilities  -  To  be  determined,  based  on 


CECOM  recommendations. 


3.9.3  Communication  Equ I pment  Suppor t  Fac I  1  1 1 1 es  -  To  be  determined. 


3.9.4  Government  Furnished  Equipment  (GFE)  -  Figure  3-12  lists  the 
candidate  Government  Furnished  Equipment  that  will  be  available  tor 
development  of  AFV  automation  and  communications  resources. 


3.10  SUPPORT  EQUIPMENT  -  In  producing  the  computer  programs  for  the 


system,  the  developers  (contractor  or  Government)  will  very  likely  use 
special  programs,  tools,  and  facilities  which  will  be  used  throughout  the 
AFV  life  cycle  for  support  of  AFV  automation  and  communications 


resources.  The  support  equipment  planned  for  AFV  will  be  consistent  with 


the  approach  taken  by  the  Government  for  AFV  software  Life  Cycle  Software 
Support  (LCSS) .  The  system  Integrator  will  have  overall  responsibility 
for  software  Integration.  The  software  development  suite  developed  m 
accordance  with  DOD-STD-2467  (AR)  at  the  prime  contractor  facilities  will 


be  transitioned  to  the  AFVTF  designated  LCEC.  The  LCEC  will  ensure 
support  of  the  fielded  AFV  software.  Plans  for  transition  of  post 
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deployment  AFV  software  support  from  system  integrator  to  Government  LCEC 
will  be  determined  at  a  later  date. 

3.11  DEVELOPMENT  RISK  ASSESSMENT  -  Computer  resource  requirements  shall 
be  continuously  coordinated  and  reconciled  with  system  operational 
requirements  throughout  the  AFV  system  life  cycle.  Resource  requirements, 
security  issues,  interface  control,  and  integration  methodology  will  be 
reviewed  as  necessary.  Assessments  shall  be  performed  before  Milestone  I 
and  II  to  identify  risk  areas  involving  automation  and  communication 
resources.  The  risk  areas  and  the  plan  for  minimizing  risk  consistent 
with  stated  operational  requirements  shall  be  identified  In  the 
acquisition  decision  documentation  at  the  Milestone  I/ll  review.  Design 
and  trade-off  studies  will  be  conducted  as  necessary  to  evaluate  potential 
risk  areas.  Risk  areas  requiring  special  monitoring  will  be  Identified 
and  procedures  for  monitoring  and  assessing  the  risk  will  be  Implemented. 
Currently  Identified  areas  of  concern  are  shown  In  Figure  3-2. 

3.12  SUMMARY ,  PROGRAM  MANAGEMENT  -  Chapter  3  specifies  management 
resources  and  organization  needed  to  accomplish  the  development. 
Integration,  and  support  of  AFV  automation  and  communication  resources. 
The  risk  Involved  in  the  development  of  these  resources  is  also 
discussed.  Figure  3-12  depicts  a  brief  milestone  summary. 
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Table  of  Government  Furnished  Software  (GFS) 
and  Government  Furnished  Equipment  (GFE) 


Equ i pment 

Agency 

0 

Maneuver  Control  System  (MCS) 

PEO  CCS 

0 

All  source  Analysis  System  (ASAS) 

PEO  CCS/IEW 

0 

Forwerd  Area  Air  Defense  Command,  Control, 

Intelligence  System  (FAA0C2I) 

PEO  CCS 

o 

Advanced  Field  Artillery  Tactical  Data 

System 

(AFATDS) 

o 

Combat  Service  Support  Control  System 

(CSSCS) 

LOGCEN/PEO  CCS 

0 

Single  Channel  Ground  Radio  System  (SI 

NCGARS) 

PEO  COMM 

0 

Mobile  Subscriber  Equipment  (MSE) 

PEO  COMM 

0 

Enhanced  PLRS  User  Unit  (EPUU) 

PEO  COMM 

n 

Vehicle  Navigation  Azimuth  System  (VNAS) 

ARDEC 

0 

Module  Azimuth  Positioning  System  (MAPS) 

ARDEC 

0 

ACCS  Common  Hardware  (when  available) 

PEO  CCS 

0 

Flat  Panel  Displays 

ETDL 

0 

Digital  Data  Entry  Devices 

ETDL 

Pub  1 i cat i ons 

AMC/TRADOC 

References 

AMC/TRADOC 

Spec i f i cat  I ons 

lopographlc  Data  Base  Standard 

ETL 

Built  In  Test  Output  Standard 

CECOM 

Vehicle  Electronic  Data  Bus  Standard 

TACOM 

Common  Graphic  Symbology  Standard 

CACDA 

Driver  Station  Standard 

CACDA 

Vehicle  Commander  Station  Standard 

CACDA 

ACCS  System  Specification 

PEO  CCS 

B2C2  User  Definition 

CACDA 

VCOS  User  Definition 

CACDA 

Sn  f  twar  e  Tools 

Topographic  Software 

To  Be  Determined 

Vehicle  Integrated  Intelligence 

To  Be  Determined 

BMS  (as  developed  to-date) 

To  Be  Determined 

F  t  gure  3- 1 1 
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MAJOR  MILESTONES 
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VCOS  TACOM/CACDA  --  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  <> 

VCOS  AFV  STUDY  CONTRACTOR  -  1  <;================<> 

VCOS  AFV  STUDY  CONTRACTOR  -  2  <>================<> 

VCOS  AFV  STUDY  CONTRACTOR  -  3  <>================<> 

B2C2  CECOM/CACDA  ==========<> 

B2C2  AFV  STUDY  CONTRACTOR  -  1  <>=  =  =  =  =  =  ===  =  =  =  =^  =  =  =  0 
B2C2  AFV  STUDY  CONTRACTOR  -  2  <>================<> 

B2C2  AFV  STUDY  CONTRACTOR  -  3  <>================<> 

AFVTF/PEO  SELECTS  BEST  VC0S/B2C2 
AFV  VCOS  DEVELOPMENT 
AFV  82C2  DEVELOPMENT 
FIELD 
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CHAPTER  4  -  ACQUISITION  MANAGEMENT 


4.1  INTRODUCTION 


This  Chapter  o-f  the  CRMP  addresses  the  acquisition  strategy  that  will  be 
followed  throughout  the  development,  acquisition,  testing,  and  fielding  of 
tne  AFV  computer  resource  items.  A  description  is  given  of  the  system 
engineering  approach  to  allocating  operational  needs  to  computer  resources 
and  critical  design  areas.  Organizational  responsibilities  and  roles  of 
the  program  participants,  and  the  acquisition  process  together  with 
deliverables  and  post-deployment  support  considerations  are  also 
discussed.  Operational  and  support  concepts  are  addressed  in  Chapter  6, 
Plan  for  Support.  Review  Chapter  1  for  the  overall  acquisition  concept. 

4.1.1  Acquisition  Strategy 


The  acquisition  strategy  of  AFV  is  straight  forward.  After  successful 
completion  of  Milestone  I/II  in  19S9  the  Director,  AFVTF  will  release  a 
Request  For  Proposal  sRFP)  for  the  AFV  Devel ooment/Prove  Out  (DPO) .  'ne 
DPQ  will  be  carried  out  as  discussed  in  Chapter  3  of  this  CRMP.  Foil  owing 
a  successful  Milestone  III,  the  Production  and  Deoiovment  Pnase  of  tne  AF'v 
program  will  commence.  The  AFV  will  be  develcoed  as  a  tcta.i  s/stem. 


4.  1 

XV-IV-1 


)  .\  r'  o  . 


AFV  CRMP 
VOLUME  XV 


"NCLA^5^-; 


1  SEPTEMBER  87 
^ACQUISITION  MANAGEMENT 


AFVTF,  in 
•fol  lowing 
per-f  ormance 


collaboration  with  other  cognizant  agencies,  will  provide  the 
computer  resource  inputs  to  the  procurement  package: 
requirements  (specifications) ,  proposal  preparation 


instructions  (instructions  to  bidders),  contract  tasks  (SOW  and  WBS) , 
deliverable  items  (contract  schedule  and  contract  data  requirements  list 
(CDRL)  )  ,  and  special  provisions.  AFVTF  will  determine  the  need  -for  and 
develop  the  types  of  special  contract  provisions  as  specified  below. 


4.1.  1.1  Computer  Develooment  Contraints  -  When  constraints,  such  as  High 
Order  Languages  (HOLs) ,  spare  memory  and  throughput  requirements,  security 
requirements,  bus  interfaces  and  interconnection,  interoperability,  and 
software  interservicing  requirements,  are  part  of  the  computer  software 
development  effort,  applicable  provisions  shall  be  clearly  stated  in  the 
SOW  and  specification. 


4.  I.  1.2 


Communication  Development  Constraints  -  Similiarly,  any 


constraints  to  the  development  of  communications  hardware  and  software 
will  be  specified  in  the  SOW  and  in  the  Specifications  for  the 
communications  hardware  or  software. 


4.1.  1.3 
1  nc  1  Lioed 
aaents 


Access  to  Internal  Contract  or  Data  -  ^n  enaPlina  clause  shall  Pe 


in  the  contract (s)  to  provide  the  Government  and  its  authcriced 
access  to  contractor  internal  A^V  cesipn  and  develop  rent 
documentation  during  all  phases  of  the  F3D  program. 


4. 1.2.4  Commercial  Computers  and  Software.  -  Procedures  will  be  developed 


and  incorporated  into  the  contract  to  ensure  that  the  contractor  reviews 
and  documents  all  subcontractor  or  vendor  changes  and  that  all  commercial 
hardware  and  software  in  the  system  is  maintained  to  the  correct 


performance  and  configuration  level. 


The  con: 
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responsible  -for  maintaining  engineering  compatibility  between  all  system 
equipment  and  software,  including  incorporation  of  newly  released  versions 
of  software  until  specifically  released  by  the  government. 

4. 1.1.5  Support  Software  Deliverables.  -  Support  software  required  to 
cost-effectively  develop  and  maintain  the  delivered  computer  resources 
over  the  system  life  cycle  shall  be  specified  as  del i vef-able;  witn  the 
provisions  for  DOD  acquiring  appropriate  rights  to  its  design  and  use. 
Examples  of  support  software  include,  but  are  not  limited  to,  operating 
systems,  compilers,  source  and  object  code  for  development  tools,  test 
drivers,  programs  and  tools,  environmental  simulators  and  analyzers,  and 
training  aids. 

4. 1.1.6  Rights  to  Computer  and  Communication  Resources  Software.  - 
Contractual  provisions  shall  reflect  the  Government's  requirements  for 
unlimited  rights  to  the  computer  and  communciation  resources  software  and 
associated  documentation.  (See  paragraph  4.6,  Computer  Program  and  Data 
Rights) . 

^.1.1.7  Subcontract  Management.  -  Computer  resources  (including  computer 
software)  may  be  developed  unoer  a  subcontract  to  a  prime  contractor, 
therefore  the  prime  contract  must  be  written  to  ensure  tnat  5ll 
appropriate  contractual  requirements  levied  on  tne  pri me , contractor  are 
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passed  to  all  subcontractors.  The  prime  contract  will  ensure  that  the 
subcontractors  are  responsible  -for  the  integrity  o-f  their  products  and 
identi-fies  the  prime  contractor  as  responsible  for  the  ultimate  delivery 
and  integrity  o-f  all  system  products.  AFVTF  reserves  the  right  to 
coordinate  directly  with  subcontractors. 

4.  1.1.8  Tai  lorinq.  -  General  system  (hardware/so-f tware)  engineering 
development  methods  will  be  tailored  to  support  the  AFV  Acquisition 
Schedule.  Engineering  development  phases  will  not  likely  require  planned 
overlap  or  parallel  execution.  The  AFVTF  or  designated  representative 
will  evaluate  applicable  military  standards  tor  computer  resource 
development  and  identi-fy  tailoring  required  to  appropriately  adapt  the 
computer  so-ftware  development  cycle  to  reflect  AFV  system  acquisition 
needs.  AFVTF  will  perform  a  similar  tailoring  of  the  data  item 

descriptions  for  software  development  products.  In  addition,  AFVTF  will 
determine  which  of  the  software  documents  are  needed  by  using 
DOD-STD-2167,  and  identify  them  as  deliverables  if  appropriate.  In  making 
these  assessments,  AFVTF  will  have  primary  consideration  to  the  need  for 
such  documents  during  the  particular  program  phase  and  within  the  content 
of  system  use  and  support  throughout  the  system  life  cycle.  Consi derat i ch 
will  be  given  as  to  the  optimum  time  for  delivery  or  procurement  o* 
necessary  software  documentation  such  that  the  oocumentat i on  is  net 
subject  to  massive  change. 

4.2.  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  Uf.S  I  &  I  i.  I  I E5 

During  the  acquisition  phase,  participants  identified  in  Chapter  3 
assume  a  more  active  role  as  described  in  the  following  paragraphs. 
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UNCLASSIFIED 


4.2.1  Government  Organization 

The  Director,  AFVTF  has  overall  responsibility  •for  planning,  directing, 
and  controlling  the  acquisition  of  the  program  and  ensuring  that  the 
requirements  of  the  JMSNS,  ROC  etc.  are  met.  The  Director  will  manage  the 
acquisition  in  accordance  with  the  program  schedule  and  goals,  ensuring 
that  each  phase  of  the  program  yields  the  results  necessary  to  support  the 
Milestone  decision  process. 

4.2. 1.1  Program  Management  Support  -  An  Automation  and  Communication 
Resources  Working  Group  (ACRWG)  will  be  established  to  aid  in  the 
management  of  the  AFV  computer  resources  acquisition.  The  ACRWG  will 
perform  reviews  and  analyses  in  accordance  with  its  charter  and  in 
response  to  tasking  by  the  Director,  AFVTF. 

4.2. 1.2  ACRWG  Functions  -  The  ACRWG  shall  assist  in  ensuring  that 
automation  and  and  communications  resources  comply  with  established 
policy,  procedures,  plans,  and  standards.  The  ACRWG  shall  continually 
support  the  AFVTF  in  computer  resource  life  cycle  planning.  The  ACRWG 
recommends  updates  to  the  CRMP,  to  ensure  that  acquisition,  user,  and 
support  reouirements  are  satisfied.  The  ACRWG  evaluates  comouter  software 
plans,  products,  and  proposed  changes  to  ensure  compatibility  with 
accepted  policies  and  procedures.  The  ACRWG  also  supports  AFVTF  in  the 
resolution  of  issues  such  as  documentation  requirements,  communi cations, 
and  support  agreements.  Special  roles  that  the  individual  particioants 
will  assume  during  acquisition  will  be  assigned  and  determined  by  tne 
ACRWG  Chair  and  reflected  in  ACRWG  meeting  minutes.  The  ACRWG  will 
require  the  system  integrator  to  report  the  contractor  computer  resources 
acquisition  management  organization  and  will  incorporate  that  organization 
into  the  CRMP  following  award  of  Development  Proveout  and 
Production/Deployment  phase  contracts. 
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4.2. 1.3  Army  Materiel  Command  (AMC) 


4.2. 1.4  Training  and  Doctrine  Command  (TRADQC) 


.v.*l 


4.2. 1.5  Program  Executive  □■f-fices 


4.2. 1.6  Program  managers 
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Contractor  Oroanization 


Review  Contractor  organizations  in  Chapter  1. 

4.3  AUTOMATION  AND  COMMUNICATION  ARCHITECTURE.  RESOURCE  ALLOCATION 


The  criteria  and  constraints  to  which  the  system  architecture  must  be 
responsive  will  be  speci-fied.  It  is  planned  that  the  specifications  for 
automation  and  communications  resources  will  mature  during 
Development/Prove  Out.  Emphasis  will  be  placed  on  top-down  design  and  the 
structuring  of  hardware  and  software  modules.  Configuration  factors  which 
may  impact  the  architecture  such  as  a  networking  of  processors, 
distributed  processing,  real-time  processing,  man-machine  interface, 
communication  processing  fail-soft  or  graceful  degradation  configuration 
will  be  specified  by  the  government  prior  to  DPO  phase.  Review  Chapter  2, 
Requirements  Analysis  for  the  architecture  definition. 


4.4  SYSTEMS  ENGINEERING  APPROACH 


The  basic  requirement  is  that  the  AFV  developers  aeliver  final  products  in 
the  approved  configuration.  Strict  adherence  to  currently  accepted  system 
engineering  methodology  will  ensure  that  the  AFV  computer  resou’^ces 
possess  the  required  high  degree  of  rel  i  abi  1 1 1 '//matur  i  ty ,  availability, 
and  maintainability  required.  Tailoring  the  engineering  cycle  (paragraph 
4.1)  must  not  alter  this  requirement. 


4.4.1  Requirements  Allocation 


Management  control  must  be  employed  to  ensure  that  the  system  requirements 
are  properly  allocated  to  the  system  hardware  and  software.  This  may 
involve  invoking  a  requirements  engineering  methodology  to  assure 
traceability  of  requirements  in  the  specifications,  test  procedures,  and 


other  system  documents- 
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4.4.2  Development  Methodology 


Special  so-ftware  development  requirements  -for  the  AFV  are  discussed  in 
Chapter  5.  These  include  the  use  O'f  Ada,  the  construction  and  use  of  a 
system  prototype,  and  the  early  establishment  and  operation  of  the 
LCSEC's.  Any  other  special  requirements  that  will  be  levied  on 

development  contractors,  such  as  the  use  of  a  program  design  language 


(PDL) ,  structured  testing,  test  case  generation,  simulation,  etc.,  will  be 
specified  in  Development  Prove  Cut  (DPO)  and  Production/Deployment  RFP's. 

4.5  HARDWARE/SOFTWARE  TRADE-OFFS 


Hardware/software  tradeoff  analyses  are  performed  to  determine  the  best 
balance  among  system  performance  characteristics,  support  resource 
requirements,  and  support  concepts.  The  principles  of  Integrated  Logistic 
Support  (ILS)  are  applied  to  both  hardware  and  software  as  a  part  of  each 
tradeoff  analysis.  This  includes  analyses  for  training  and  diagnostic 
equipment.  The  analyses  performed  will  include  consideration  of  the 
effects  of  the  software  design  and  post-devel ooment  software  software 
change  fielding  methodology  on  overall  AFV  system  and  subsystem 
F'eliabilitv,  Aval  1  abi  1 1  tv,  and  Mai  ntai  nabi  1 1 1  v  fPAM)  .  ^artiCLiIar  emohasis 
will  be  placed  on  identifying  and  including  in  the  logistic  anal/ses,  tne 
full  or  partial  loss  o-*  reauired  cpe^atic'ai  cacacilities  as  tne-  s'^e 
affected  by  the  amount  cf  time  and  qtantitv  o*  •■esou.rces  needed  cc 
distribute  and  install  software  changes  worlcwiae  to  AFV  svstems  and 
support  equipment.  The  time  and  effort  needed  to  develop  and  field  the 
software  improvements  identified  by  programs  such  as  MANPRINT  will  also  be 
considered.  The  results  of  the  software  analyses  will  be  merged  with 
those  from  the  hardware  analyses  to  determine  assembly,  module,  and  system 
RAM. 
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Based  on  previous  experience  with  functionally  similiar  software,  the 
combat  developer  with  assistance  from  the  materiel  developer,  will 
establish  an  expected  frequency  for  fielding  post-development  software 
changes.  This  frequency,  i.e.,  the  Mean  Time  Between  Maintenance  (MTBM) , 
will  be  utilised  in  determining  the  life  cycle  cost  in  any  tradeoff 
analysis  used  to  determine  whether  to  implement  a  function  in  hardware, 
software,  or  firmware.  For  the  purpose  of  fielding  software  changes,  the 
Mean  Time  To  Repair  (MTTR)  a  hardware  assembly  containing  the  software 
will  be  taken  as  the  hands-on  time  required  to  gain  access  to  the  hardware 
containing  the  software,  swap  out  the  hardware  or  load  new  software  into 
the  existing  hardware  devicesis),  reassemble,  and  test  the  system  to 
verify  proper  operation  of  hardware  and  software. 

The  effects  of  post-development  fielding  of  software  changes  on  life  cycle 
cost  will  also  be  considered  in  establishing  the  design  of  all  new 
hardware,  in  selecting  existing  hardware  for  inclusion  in  the  production 
system,  and  in  determining  the  level  of  system  readiness  provided. 
Primary  design  goals  will  include  the  minimizing  of  spares  required  to 
field  a  software  change,  minimizing  or  eliminating  the  cost  of  purging 
obsolete  software  from  the  supply  system,  and  utilizing  the  on-site 
o-ganizaticnal  maintenance  personnel  to  install  software  changes.  Any 
decision  to  use  firmware  and  all  hardware/ software  traoeoff  decisions  will 
be  supoorted  bv  a  life  cvcle  cost  analysis  dsmcnstr at i no  tnat  t“e  oecisicn 
results  in  the  lowest  life  cvcle  cost  ‘•or  provioing  the  raouired 
capabi 1 1 ty . 


Software  Acquisi 1 1 on 


Software  requirements  will  dictate  the  acquisition  of  hardware  components 
and  firmware.  Software  will  be  acquired  and  used  to  implement  complex 
functions  with  a  high  probability  of  change 
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ilFIED 


4.5.2  Hardware  Acquisition 

Hardware  acquisition  is  -favored  -for  the  implementation  o-f  simple, 
Iterative  tasks  with  a  low  probability  o-f  change. 

4.5.3  Firmware  Acquisition 


The  combination  o-f  associated  computer  instructions  and  computer  data 
definitions  required  to  enable  the  computer  hardware  to  perform 
computational  or  control  functions  is  defined  as  computer  "software".  The 
definition  of  software  is  independent  of  the  medium  on  which  the  software 
resides.  Computer  instructions  and  data  that  reside  as  read-only 
information  on  a  hardware  device,  i.e.,  "firmware",  will  be  considered 
software.  Firmware  will  be  developed,  managed,  and  documented  as 
software.  Firmware  development  equipment,  read-only  memory  programming 
equipment,  and  read-only  memory  devices  will  be  managed  and  documented  as 
hardware. 


4.5.4  Communication  Svstem  Acquisition 


4.6  3TMr;DARDI  Z4TI0N  AND  CC'MMONALITV 

✓ 

Standardization  (review  para  3.8,  stanoardi zati on  and  proven  approach)  and 
commonality  considerations  are  the  major  factors  in  reducing  the  ris)s 
associated  with  the  acquisition  of  the  AFV.  These  ^actors  reduce  the  ris). 
and  cost  associated  with  new  products,  provide  a  case  of  e;:perience,  and 
reduce  logistics  concerns.  Examples  of  A-v  commonality  and 

standardi cat  1  on  considerations  are  reflected  in  the  following  common 
requirements: 
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o  Ada  Programming  Language 

o  Standard  Data  Bus  Networks  and  Interconnections 
o  Standardized  Instruction  Set  Architecture  Hardware 

o  Displays  (Fighting  Stations) 

o  Vehicle  Control 

o  Diagnostics  Modules  (with  built  in  test) 

o  Prognostics  Modules 

o  Embedded  Training  Modules 

o  Communication  Systems  and  Control  Module 

o  Graphics  Support  Module 

o  Intercom 

o  Environment  Control 

o  Power  Inter-face  (s) 

o  Test  Measurement  Diagnostic  Equipment 
o  Automatic  Logbook 


4.7  COMPUTER  PROGRAM  AND  DATA  RIGHTS 

The  Government  will  have  unlimited  rights  to  communication  and  comouter 
programs  and  data  required  in  the  acquisition  and  life  cycle  support  o* 
the  AFV,  Any  e;-.ecotion  must  be  approved  Dy  the  Government  in  accordance 
with  D0D-5TD-1^67/1479.  These  rights  will  include  the  right  to  use. 
modify,  combine,  reproduce,  and  distribute  all  comouter  programs  and 
associated  documentation  necessary  to  the  support  concept  stated  in  this 
CRMP. 

4.8  MASTER  ACQUISITION  SCHEDULE 


The  acquisition  schedule  for  the  AFV  is  shown  in  Figure  4-1.  Milestones, 
events,  and  actions  which  are  key  to  the  timely  development  of  the  AFV 
computer  resources  are  shown  in  Figure  4-2  in  the  context  of  the  overall 
acquisition  schedule  and  specifically  detailed  in  the  AFV  FSD  proposal. 
These  schedules  will  be  reviewed,  updated,  and  reflected  as  revisions  to 

the  CRMP  during  the  life  of  this  program. 
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4.9  AFV  INTERFACES 


AFV  inter-faces  can  be  divided  into  two  basic  categories:  internal  and 
external.  The  internal  interfaces  are  comprised  of  the  vehicle 

automation,  communication,  and  electronic  architecture  components.  The 
e>:ternal  interfaces  are  comorised  of  off-carriaqe  command,  control, 
communication,  and  TMDE  systems. 


4.9.1  Internal  Interf aces 


4.9.2  E::ternal  Interfaces 


'.0  cRC;*!’'*-  REC"_' IRE'*’E'- S 


Tne  AFV  developers  will  Pe  required  to  design  software  and  selectee 
hardware  that  incorporates  features  for  future  growth  capaoility, 
modularity,  and  ease  of  modi f ication.  The  contractor  will  devise 
guidelines  and  methods  to  allow  for  ease  of  software  revisions  and 
maintenance.  The  AFVTF  will  ensure  that  software  is  designed  in 

accordance  with  the  Computer  Software  Development/Design  Speci f i cat i on ( s ) 
through  both  formal  and  informal  review  procedures. 
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4.10.1  Memory  Growth  Requirements 


4.10.2  Processing  Capacity 


4.10.3  Input/Outout  Capacity 


4.10.4  Data  Bus  Growth 


The  bus  architecture  is  designed  to  support  modular  systems. 


4.10.5  Communication  System  Growth 


4. 13 
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4.11  DOCUMENTATION  ACQUISITION 

The  documentation  requirements  -for  the  acquisition  and  support  o-f  the  AFV 
computer  resources  will  be  specified  in  RFP's  prior  to  award  of 
Development  Proveout  and  Production/Deployment  (or  FSD)  phase  contracts. 
The  ACRWG  will  include  those  specifications  in  a  planned  revision  of  the 
CRMP.  As  a  minimum  user  documentation  will  be  developed  concurrently  with 
hardware  and  software.  It  is  envisioned  that  technical  bulletins,  user, 
and  command/staff  guides  will  be  created.  Documentation  medium  (paper, 
visual  display)  has  yet  to  be  determined. 


4. 14 
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4.11.1  Government  Furnished  Documentation 

Government  -furnished  acquisition  and  support  documentation  includes 
requirements  documents  and  documentation  -for  other  Army  systems  with  which 
the  AFV  must  inter-face.  This  documentation  establishes  the  functional  and 
operational  requirements  for  the  AFV.  The  automation  and  communications 
resources  functional  and  operational  requirements  will  be  developed  from 
the  acquisition  documents  and  incorporated  into  a  planned  revision  of  the 
CRMP.  Review  Figure  3-4,  Government  Furnished  Equipment  and  Software. 

4.11.2  Contractor  Provided  Documentation 

Contractor  furnished  documentation  will  be  prepared  and  delivered  in 
accordance  with  the  Contract  Data  Requirements  List  (CDRL) . 

4.12  SUPPORT  FACILITIES 

4.12.1  Automation  Support  Facilities 

Computer  support  facilities  for  AFV  Hardware  and  software  resources 
support  are  introduced  in  Chapter  3  and  discussed  in  Chapter  t. 

-.12.2  Comrriur  1  cat  1  Bu poort  -acilitiss 


4.12.3  Development  Support  Facilities 

The  system  integrator  will  facilitate  design  and  develop  software 
development  facilities  needed  for  AFV  software  integration  and  testing. 
These  facilities  will  include  the  Life  Cycle  Software  Engineering  Center 
or  centers  (LCSEC) .  During  Development  Proveout  (DPO) ,  the  LCSEC  will  be 
used  '  XV- IV- 18  to 
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integrate  and  test  so-ftware  components.  During  Production/Deployment,  the 
LCSEC,  under  direct  control  oi  the  AFVTF,  will  be  the  •focal  point  -for 
maintenance  o-f  AFV  automation  and  communications  resources. 


4.12.4  Deployment  Support 


Prior  to  deployment  o-f  the  AFV  the  system  integrator  will  pass  control  of 
the  software  aevelopment  and  support  facilities  to  the  AFVTF  LCSEC. 


4.12.5  Post  Deployment  Support 


The  AFVTF  LCSEC  will  operate  the  software  deyelopment  and  support 


facilities  for  post-deployment  support  of  the  AFV. 


4.13  CQNF I SURAT  I  CM  MANAGEMENT  CONCEPTS 


Configuration  management  of  communication  and  computer  resources  for  the 
AFV  is  described  in  Chapter  7  of  the  CRMP.  Configuration  management  will 
be  implemented  by  the  system  integrator  under  the  superyision  of  the  AFVTF 
ACRWG.  During  post-deployment  of  the  AFV,  configuration  management  will 


De  accomplished  b-.'  tne  AFV  LCSEC  under  the  supervision  the  AFVTF. 


.-i'iCVER 


Tne  responsibility  for  management  of  the  support  of  computer  resources  for 
tne  AFV  will  pass  from  the  contract  integrator  to  the  AFVTF  LCSEC 
following  deployi..w  the  AFV. 


4.15  SUMMARY,  (■  'UIS I TION  MANAGEMENT 


Chapter  4  discu  ses  the  acquisition  of  automation  and  communications 
resources  for  the  AFV.  Review  the  AFV  Acquisition  Strategy  and  Integrated 
Logistics  Support  Plan,  Volume  III. 
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CHAPTER  5  -  DEVELOPMENT  MANAGEMENT 


i.l  INTRODUCTION 


This  Chapter  addresses  the  management  approach  to  be  utilized  during  tne 
development  AFV  computer  resources,  the  tools  to  be  used,  the  necessary 
•facilities,  and  the  associated  costs  and  schedules.  The  actions  necessary 
•for  the  development  and  delivery  o^f  speci-fi cations  and  the  required 
support  resources  are  also  identi-fied.  The  AFVTF  management  strategy 
during  the  computer  resources  development  cycle  within  the  AFV  system  Li-fe 
Cycle  15  to  maintain  necessary  visibility  o-f  the  TRADOC,  AMC,  and 
contractor's  managerial  and  technical  activities,  to  apply  management 
controls  in  a  timely  manner,  and  to  ensure  that  system  requirements  are 
zost-ef -f  ecti  ve. 


5-2  DEVELOPMENT  ORGANIZATIONS 

Development  o-f  automation  and  communications  resources  -for  the  AFV  will 
require  AFVTF  management  o-f  development  contractors  and  system 
1 ntegrators. 

5.2.1  A“-mored  ^jmilv  o-f  Verizles  Tast  Force  'ArVTF! 

The  Director,  AFVTF  monitors  the  development  process  and  has  overall 
management  authority  for  the  design,  test,  integration,  modification,  and 
production  of  the  AFV  computer  resources.  The  Director,  AFVTF  is 
supported  by  the  Task  Force  staff,  the  US  Army  commands/agencies,  and  the 
Automation  and  Communications 


5. 1 

XV-V-1 


AFV  CRMP 
VOLUME  XV 


jNCLASS.'FiED 


1  SEPTEMBER  87 
DEVELOPMENT  MANAGEMENT 


Resources  Working  Group  (ACRWG)  identi-fied  in  Chapter  3  o-f  this  CRMP. 

5.2.2  Development  Contractors 

Contractor  e-f-fort  will  be  used  tor  the  design,  testing,  integration, 
documentation,  and  production  o-f  the  AFV  computer 

resource  items.  Figure  5-1  shows  tne  planned  structure  o-f  the  system 
integrator  AFV  Computer  Resources  development  organi zati on . 

5.2.3  System  Integrator 

The  system  integrator  is  responsible  -for  ver  i -f  i  cati  on ,  validation,  and 
integration  o-f  communication  and  computer  resource  items  into  the  AFV. 

5.2.4  Army  Materiel  Command  (AMC) 

AMC  will  serve  as  the  materiel  developer  -for  the  AFV  automation  and 
communci  ations  resources.  Detailed  repsonsi  bi  1 1  ti  es  -for  AMC  and 

subordinate  commands  are  in  Chapter  3.  Close  coordination  with  TRADGC 
users  and  testers  and  with  the  AFVTF  will  be  required 

5.2.5  Training  ang  Doct-'ine  Commang  'TRADOCi 
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0.0.6  Pf**  and  ^'EQ  Qroanizations 


EO^MOAL  iND  “'ANAGEMEN't  OON'^RQLS 


T-ie  APVTP  will  aevelcp  and  apply  the  management  and  technical  contrale 
necesaarv  to  monitor  so+tware  production  py  conf^actore .  Traceability  or 
reG'ji''9pment5  and  pericdic  status  reviews  are  primary  controls  to  be  used, 
^ne  system  integrator  will  be  the  central  -fcca.l  point  -for  the  management 
0*  scTtware  development.  ’’’he  system  integrator  will  operate  or  coordinate 
.-.if  t'e  -IEEE  S'  ci."'i"g  cevelopment  and  will  accomclish  svstems  ie.el 
i'tec-atior  anc  testing.  Tne  AFVT-  will  conpuct  sortware  development 
reviews  at  tne  system  integrator  s  -facilities. 


■ems'ts  T»-3ceab:  1  itv 


■  e  0  v  1  e  ’Ti  e  r 


■  1  cat  1  on 


tte'ciaa  to  '“.lew  t-e  soeci i  cat  i  p"s  .  tea:  ;  :c .  ne-^  t  a  1 1  cn  'c.a's. 
P’^ccecures ,  and  results;,  and  source  cooe.  ”ne  svstem  intec^ator  will  oe 
responsible  -for  tne  validation  o-f  computer  resource  items  to  requirements 
documents  and  for  presentation  of  traceability  analyses  to  the  AFVTF  for 
review. 
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5.3.0  Rgvigw  ang  Augits 


Governnent  reviews  t‘ie  so-ftware  aevelopment  e+'fort  will  be  required 

Curing  Development  Proveout  and  during  Production/Deployment  and  will 
include  review  ot  speci i  cati  ons ,  inter-face  control  drawings,  test  and 
evaluation  plans.  test  procedu'^es,  ana  test  reports.  Reviews  will  be 
conducteC  lAw  riL-5’’[.-i52i£i  and  will  ensure  an  orderly  so-ftware 
development  program.  "^nis,  combined  witn  tne  normal  AFV  program  reviews 
and  auoits  will  provide  tne  Director,  AFVTF  with  visibility  into  the 
contractor  s  managerial  and  tecnnical  activities.  Director,  AFVTF  will 
continually  evalL.ate  ccnt-'actor  per-f crmance ,  identHy  problem  areas,  and 


ik-e  corrective  actions. 


romputer  resource  activities  will  accomplished 


1 a  logical  ang  oraerlv  manner  consistent  with  contract  requirements. 
E.  isting  commercial  ott-the-snel-f  computer  products  will  be  considered  tor 


acmini  st-'atior 


Id  jcsical  application  it  tney  contain  the  necessary 


performance  anc  information  reauired  b>  tne  Contract  Data  Requirement  List 
(CDRL).  Government  review  O'f  tne  contractor  developed  specifications  will 
be  cpnaucted  at  designated  majoi^/minor  contract  milestones  as  specified  in 
tne  De.'eiopment  ^•■c-'eout  :DrG<  and  Producti on/Dep  1  oyment  contract  (s)  .  Tne 
♦cllowi-g  .--C'mai  arc  -c-mai  reviews  may  be  specified  and  used  by  the 


Svstem  r ep'j.i r ements  Review  (5RR 
Eysteifi  Design  Review  ',5DRJ 
Software  Speci f ication  Review  (SRR) 
Preliminary  Design  Review  (PDR) 
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Desian  Peview  (ODR) 


Formal  Qual  i -f  i  cat i on  Review  (FOR) 


-.inctiomal  con-f  i  aurat  i  on  Audit  (FCA) 


PPvsical  Con-f  1  ourati on  Audit  (PCA' 


j  0  \/  9 ;  c  r  0  n  * 


*.  C- '  -  r  p  •  - 


anc  Lcr 


»-•  r  .  .  r  W 1  , 


:tor  ceveloBS  ano  maintairc  clans  tor  acttware  oeveloomt 


in  ccn=cnance  witn  t'e  LO^-ernment  s  cvera.i  ccmouter  resource  lin  = 


^na  Development  Activity 


ensure  tnat  tne  contractc 


revel  ops  computer  resource  pians 


sc'ftwa''e  enoineermc  manacement 


iQuration  management 


sottwa'"e  quality,  reliadility, 


■Tcintai  naoi  1  itv,  security,  lidrary,  interfaces,  data  manaoement .  an 


syatem  satetv  ir  accordance  witn  the  requirements  of  tne  SOW.  T^ 


Development  Activity  will  ensure  that  tne  contractor  estaPlisnes  a- 


■amtains  management,  financial,  and  tecnnical  controls 


to  positive. 


loentifv  anv  ceviations  f-om  plans.  ‘^ne  Development  Aptivitv  will  tra: 


f'e  ppntraptpr  s  utilicaticn  of  pomouter  resourpes  to  assure  tnat  tn 


oo-t-aoto"  porplies  witr.  estaolisned  maroins  ^or  reserve  capaoit.. 


Status  a"0  Dost  Peportmc  -  AFV'F  will  e^-sure  tnat 


'■  a  1  -  t  a  1  n  s  s  o  n  e  c 


r'.f".  c  .  =  0  =  « 


ir  zzi^  *  tne  tzv.- 


vsl*!  I  '  Cl  Z 


.“i£t  t"0  zz-^  e  «ev0lzt*e“t 


ze  cn  e 


''-.tZ’n?t9t  GZ  r"  0.fr<  '^0n0ze'‘'0rt 


analyze,  anc  Gisolay  management  data. 
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Program  Management  Control  Svstem  (PMCS) 


5.4  QUALITY  ASSURANCE 


The  system  integrator  and  developers  will  establish  and  maintain  an 
on-going  quality  control  program  tor  the  software  development  process,  and 
per-form  tests  to  demonstrate  compliance  of  the  computer  programs  with  the 
specified  requirements.  Design  methodology  is  explained  below;  testing 
methodology  is  explained  in  Chapter  6.  The  following  quality  assurance 
procedures  will  be  adhered  to  in  order  to  maintain  quality  control: 


o  Participate  in  al  formal  reviews  and  waU.throughs  to  ensure  their 
comoleteness  and  accuracy 

o  Review  and  take  part  in  the  approval  of  all  developer  submittea 
software  documentation 

■p  Maintain  appropriate  records  of  all  assessrr.ents  ano  tests  in 
sjpDcrt  of  the  following  activities 


A.  Management  decision  points 

B.  Program  validation 

C.  Post  deployment  baseline  change  evaluation 

D.  Post  deployment  test  management 

E.  Technical  data  base 


o  Advise  the  Director,  AFVTF  on  the  performance,  quality,  and 
supportabi 1 i ty  of  the  software  program 


5.7 

XV-V-7 


t  *  m  "  IL  '  •  •  •  " 
II  ^  ft 


AFV  CRMP 
VOLUME  XV 


UNCLASSIFIED 


1  SEPTEMBER  87 
DEVELOPMENT  MANAGEMENT 


o  Per-form  continuous  assessments  of  the  developer  Software  Quality 

Assurance  (SDA)  Program  to  ensure  that  reviews,  audits, 
verification,  testing,  and  procedural  and  product  aspects  of 
system  development  are  performed  lAW  the  guidelines  of  Section  5.9 
of  DOD-STD-1679,  MIL-S-5779  and  contract  requirements 
o  Evaluate  and  approve  the  final  IV?(V  Plan  and  monitor  the  actual 
acceptance  test  of  the  software  program  to  ensure  all  reauirements 
and  documentation  are  verified 

o  Assure  that  the  SQA  Plans  are  acequate  and  meet  required 

gui del  1 nes 

5.4.1  Human  Factors  Engineer i nq 


1.4.2  Software  Desian  flethodol oov 


Developers  will  use  a  design  methodology  that  conforrs  to  t~e  So'.e'''''' 
spec  1  f  1  cat  1  on  and  internal  coroorate  requirements  as  aoo'^o.sc  ov  ■ 


government , 


This  methoaology  will  include  a  too-co.-.r 


ent  manacement  reviews 


:o  prcvice 


software  development  status.  C0D-5TD-2167  shai  1  os  '..=^0  a; 
Review  the  Development  Philosphy  in  Chapter  C,  Frcgram  r.anageiTier.  t . 


5.4.2. 1  rethodoloqy  -  Computer  software  development  entails  activities 

described  below  and  will  be  in  conformance  with  the  cont-act 

requirements.  Although  described  as  sequential  activities,  tne  use  of  a 

top-down  development  approach  may  cause  computer  software  ceveioonent 

activities  to  proceed  concurrently.  Different  portions  of  the  compute'^ 

software  may  be  developed  in  parallel;  however  each  will  proceed  through 

Requirements,  Analysis,  Preliminary  Design,  Detailed  Design,  Coding,  Unit 

Testing,  and  CSC  Integration  and  Testing,  CSCI  Testing,  System  Integration 
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and  Testing,  and  Operational  Testing  and  Evaluation  o-f  the  Engineering 
Li-fe  Cycle. 

5. 4. 2. 2  Requirements  Analysis  -  A  complete  set  o-f  -functional  and 

per-formance  requirements  will  be  established  -for  each  Speci -f i cati on .  The 
requirements  analvsis  will  continue  during  the  DPO  Phase  to  completely 
de-fine  the  requirements.  Inter-face  requirements  will  be  defined  between 
sc-ftware  and  hardware  speci-f ications.  ,  All  adaptations  needed  to 

accommodate  di-f-ferent  user  sites  shall  be  identi-fied.  Requirements 
analysis  will  evaluate  requirements  -for  completeness,  consistency, 

adequacy,  testability,  understandabi 1 i ty ,  and  supportabi 1 i ty .  As  mission 
needs  change,  continuous  analyses  will  be  required  to  determine  to  impact 
on  SQ-ftware  requirements. 


developed 
consider 
studies , 
compute'' 
centre:  -f 

CSC  le-.'el 


Preliminary  Design  -  A  modular  top-level  so-ftware  design  will  be 
-from  the  so-ftware  requirements.  The  design  process  will 
various  aesign  alternatives,  analytical  results,  trade-o-ff 
and  capability  to  accommodate  change.  The  design  will  identi-fy 
software  camponents  (CSCs)  and  snail  define  the  data  interfaces, 
low,  and  resource  budgets  for  memory  and  e::ecuticn  time  at  the 
.  P'unctional  software  requirements  shall  be  assigned  to  CSCs  of 


tbe  t'Op-ies-el  design.  Initial  data  base  designs  will  cefine  the  st'"'w',ct'wi.re 
and  o'cani cation  of  the  data  base. 


5. 4. 2. 4  Detailed  Software  Desion  -  Detailed  software  oesign  will  refine 
the  CSCs  of  the  top-level  software  design  to  successively  lower-level 
design  elements  until,  at  the  lowest  level,  they  specify  individual  units 
to  be  developed.  The  detailed  design  will  define  all  information  required 
for  coding  these  units,  including  control  logic,  algorithms,  data, 
accuracy,  and  timing.  For  any  interfaces  vuth  other  software  and  hardware 


5.9 
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spec  i  +  i  cat  ions  detailed  inter-face  design  will  precisely  define  data 
formats,  data  flow,  and  timing  constraints  in  sufficient  detail  for  coding 
data  structures  and  control  routines.  Data  base  designs  shall  be  defined, 
including  constituent  items,  fields,  records,  and  files. 

5.4.3  Hardware  Desipn  Methodoloqv 


5.4.3. 1  Computer  Hardware  Desian 


,4.3.2  Communication  System  Desian 


5.4.4  Duality  Assurance  Plan 

A  developer  software  quality  system  will  be  documented  m  a  Duality 
Assurance  (DA)  Plan  lAW  D0D-STD-I67?.  The  plan  will  present  t‘’e 

contractor  quality  organitation ,  standards,  procedures,  tacilities,  arc 
reporting  system.  The  ACRWG  will  incorporate  contractor  DH  plj-is  i"to  t“e 
CRMF  after  contract  award.  Anv  special  requirements  wrier  xa'/  ce  ircctsd 
on  the  contractor  will  be  included. 

5. 4. 4.1  Software  Quality  -  The  integration  contractor  (s)  will  implement 
quality  assurance  plans  under  the  supervision  of  the  AFVTF  throughout  the 
DPO  Phase.  The  AFVTF  will  ensure  that  the  contractor  plans,  defines,  and 
executes  adequate  software  quality  procedures  for  all  software  develooment 
activities  and  products. 

5.10 
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5. 4. 2. 2  Independent  Veri-f  ication  and  Validation  (IVS>V)  -  AFVTF  will 

implement  IV?<V  procedures  during  development.  Procurement  activities  -for 
the  IV!«V  e-ftort  will  be  completed  as  soon  as  practicable  to  allow  -for 
independent  veri-f ication  o-f  the  so-ftware  products.  The  IV?yV  -function  will 
be  per-formed  by  the  system  integrator.  AFVTF  will  define  the  interface 
between  the  IV?<V  agency  and  the  development  agencies;  provide  the  IVS-V 
agency  with  copies  o-f  the  aopropriate  development  soeci-f ications,  desion 
documents,  listings,  and  technical  data;  and  monitor  the  sati s-f actory 
resolution  o-f  all  discrepancies  -found  by  the  IV!iV  agency.  IMW  will  be 
supported  by  an  IV?!V  Flan  which  will  be  develooed  by  a  Government  agency 
'to  be  determined). 

5.5  DEVELOPMENT  SCHEDULE 


Tne  development  schedule  -for  the  AFV  computer  so-ftware  programs  is  shown 
in  Figure  5.2.  An  e:;oahded  development  schedule  is  located  at  Appendi:^  -J . 

5.6  STATUS  REPQPTING  AND  MONITORING 


Development  mioni  to^'i  ng ,  -formally  and  :n-fcrmally,  and  status  reoortinc 
procedures  provide  the  primary  means  bv  which  tre  AFVTF  will  montor 
50-ftware  program  development  e-^forts.  I'he  Wort  Dreau  down  Strupture  -WrS) 
--tctliahes  the  fr^meworr  -r.pr  reporting  p-'ocram  cost,  schedule  and 
technical  per-formance  and  is  the  oasis  -^or  uni-form  planning,  stat'us 
reporting,  program  visibility,  and  assignment  o-f  responsi bi  1 1 ti es.  Tne 
contractor  (or  developer)  will  be  required  to  report  in  accordance  with 
the  individual  CDRL's  and/or  established  milestones. 
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Computer  So-ftware 
Development  Schedule 
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5.6.1  Pr o j ect  Milestone  Charts 


Per  contract  requirements,  the  AFV  developers  will  submit,  project 
milestone  charts  which  shall  graphically  depict  the  major  program 
milestones  and  [contract!  deliverables  and  report  o-f  the  actual  work 
status  against  the  planned  activities.  These  reports  will  aid  the  AFVTF 
in  the  timely  analysis  and  resolution  c-f  each  anomaly  or  de-ficiency, 
especially  in  the  area  ot  time-critical  computer  so-ftware  program 
devel cpment . 


5.6.2  Status  Reports 


All  Developers  and  supporting  organizations  will  be  required  to  report 
technical  progress  on  a  regular  basis.  This  report  will  describe 
technical  progress,  accomplishments,  assessments  o-f  progress  in  terms  ot 
schedules,  potential  problems,  contingency  plans,  plans  tor  scneaule 
recovery  tor  items  which  are  behind  schedule,  and  plans  -for  tne  ■following 
time  frame.  As  backup  ■►or  this  deliverable,  the  developer  will  implement 
an  internal  so-ftware  ta£^  management  system  wnich  will  indicate  -for  each 
software  program/ta£^  tne  personnel  assigned,  the  planned  scnedule,  ano 
tne  c:.r'-ent  status.  “Ms  oata  will  be  aval  ladle  for  ■'e'.'iew  b'v  tne 
gave‘*niment  or  its  representative  as  deemed  necessarv  py  tne  C’' 

■■ec'jired  in  accc'dance  with  tne  AFV  FSD  Contract 


5.  7  2EVELL!^'MENT/r£5T  REEQURCE  REQUIREMENTS 

The  resources  required  for  the  development  and  test  of  the  AFV  computer 
software  programs  will  be  provided  by  the  contractor  as  apart  of  the 
Software  Development  Station  (SDS)  operational  requirements.  The  SDS 
requirements  and  necessary  resources  are  described  in  the  paragraphs  which 
f ol  1 ow. 
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5.7.1  Growth  Capacity  and  Supportabi 1 itv 

These  are  areas  where  proven  concepts  and  existing  computer  resources  will 
be  used  during  development,  test,  integration,  production,  and  deployment 

of  the  AFV.  As  discussed  earlier,  military  standard  hardware  and  software 

may  be  utilized  if  practical.  In  addition,  AFV  planning  emphasizes  use 
of  the  following  resources. 

o  Automated  Configuration  Management  Support 

o  Automated  Documentation  Support 

o  Computer  Software  Programs 

o  Common,  Standard,  and  Reusable  Software  Modules  or  Components 
o  Proven  and  thoroughly  tested  Algorithms 
o  Test  Facilities 
o  Software  Development  Station (s) 
o  Simulators/Emulators 
o  Prototypes 

5.7.2  Software  Analysis 

Software  selection  snould  be  based  on  e:;Dectsd  certcmance  coals. 
Algorithm  analysis  should  be  based  on  correctness,  amount  o*  wor^  cone, 
amount  of  work  accomplished,  space  used,  simolicitv,  coti mal i tv , 
testability,  and  mai ntai nabi  1 1 ty.  This  directly  inDiies  that  sc'tware 
modules  should  be  small  and  will  be  documented.  Algorithm  complexitv  m 
best,  worse  and  average  cases  should  be  less  than  polynomial. 

5.7.3  Hardware  Facilities 

Specific  hardware  configurations  will  be  presented  in  the  CRMP  when 
defined.  Typically,  target  vehicle  hardware  will  not  be  available  until 
the  Devel opment/Proveout  (DPO)  Phase. 
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Therefore,  so-ftware  development  on  mainframe  computers  should 
simulate/emulate  (to  include  input/output  per-f  ormance)  the  Fighting 
Vehicle  (FV)  environment.  Hardware  con-f iguration  in-formation  will  be 
incorporated  into  the  CRMP  during  a  scheduled  update  cycle. 

5.7.4  Support  So-ftware 

'!'he  development  support  so-ftware  11  include  tools  tor  editing, 
compiling,  assembling,  linking,  deb,.iging,  testing,  simulating,  and 
documentation  to  -facilitate  rapid  correction,  test,  verification,  and 
maintenance  of  program  modules.  Automatic  so-ftware  documentation  support 
IS  an  absolute  necessity.  All  so-ftware  simulators,  test  programs,  and 
data  bases  created  to  e:;erci3e  and  assist  in  the  verification  of  the  AFV 
functional  design  will  be  documented. 

5.7.5  Manaoement  and  Control  Software 

Capabilities  of  the  Software  Development  Station  (SDS)  to  support  the 
management  process  will  be  presented  here.  This  will  include  such  iten-iS 
as:  access  control,  status  reporting,  module  interface  verification, 
library  control,  and  job  activity. 

5.6  DE-ICISNCY  ^Ar-iAGEYENT 


Deficiencies,  errors  or  faults  are  often  tnougnt  of  as  adverse  results  o-:^ 
running  hardware  components  or  testing  a  program.  Deficiency  or  error 
management  occurs  throughout  the  engineering  life  cycle.  There  are  user 
requirements,  technical  specifications,  and  program  errors.  Chaotef  6, 
Test  and  Evaluation,  and  Chapter  7,  Plan  for  Support  also  contains 
deficiency  management  guidance. 
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So-ftware  de-ficiency  management  is  the  reporting,  monitoring,  and 
resolution  of  computer  program  errors  and  deficiencies  during  development 
and  testing.  It  includes  the  establishment  of  reporting  criteria,  report 
preparation  and  routing  instructions,  and  the  action  agency's  report 
handling  procedures. 


i.3.2  Specification 


Management 


This  class  of  error  or  deficiency  management  is  related  to  errors  found  in 
user  requirements  and  faults  in  program  specifications.  Testing  is  not 
the  only  way  of  detecting  these  deficiencies.  Specification  develooers 
will  employ  a  system  to  detect  and  correct  such  problem  areas. 


5.8.3  Hardware  Deficiency  Management 


5.9  SIZING.  TIMING  OMD  PERFORMANCE  MANAGEMENT 

The  cevelooer  will  preoare  and  mai r.tai n  timing,  sizing,  and  zerfzrnanzs 
data  and  estimates  which  will  be  reported  in  accorcance  witn  appropriate 
CDRL  items.  MethoPs  for  recording,  reporting,  analyzing,  and  monitoring 
the  sizing,  timing,  and  performance  of  critical  programs  will  be 
Identified.  Automated  performance  evaluation  suites  will  be  used  for 

consistency  in  the  evaluation  of  software  performance. 
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5.10.3  Status  Accountinc 


Developers  representatives  will  periodically  review  the  con'f  i  gurati  on 
management  status  accounting  documents  (configuration  index,  change  status 
reports,  etc.)  to  ensure  that  all  proposed  or  approved  changes  are  tracked 


to  provide  traceability  throughout  the  software  development  cycle  of  the 


AFV  program  life  cycle. 


5. 10. 4  Audits 


Periodic  audits  will  be  performed  on  Configuration  Management  (CM) 
practices  to  assure  compliance  with  the  CM  Plan,  applicable  contractor 
standards  and  procedures,  and  contract  requirements.  The  AFVTF  (LCSEC) 
representative  will  also  attend  the  Functional  Configuration  Audit  (FCA) , 
Physical  Configuration  Audit  (PCA) ,  and  Functional  Qualification  Reviews 
(FQR)  to  verify  and  certify  product  integrity  prior  to  acceptance. 


5.11  GPQNTH.  MODULARITY  AND  MODIFICAT I ON 


I'uring  periodic  reviews  features  for  planned  and  actual  growth  capability, 


rodularitv,  and  ease  of  modification  will  be  examined. 


5.12  :'aC'J'^E’'JTA"IC'N  PLAN 


5.12.1  General  Aporoach 


Documentation  is  an  integral  part  of  software  through  all  phases  of 
development,  including  system  integration  and  test.  AFV  program 
documentation  shall  provide  a  continuous  representation  of  the  evolving 
state  of  the  software,  providing  traceability.  The  documentation  aids  the 
developer  m  maintenance  and  operation  of  the  software.  Since  the 
documentation  is  an  integral  part  of  the  development  process,  it  provides 
visibility  to  management  of  the  status  of  software  throughout  its  life 
cycle.  Developers  must  have  automated  support  in  this  area. 
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5.12.2  Traceabi 1 ity 

Traceability  by  documentation  shall  be  implemented,  as  -follows: 

5.12.2.1  Cross-Re-f erence  Traceability 

Cross-reference  traceability  requires  that  there  is  a  section  of  each 
software  document  that  references  related  documents.  Tnis  provides  tne 
aDility  to  locate  associated  hardware,  software,  and  interfaces.  The 
documentation  also  reference  appropriate  system  specifications.  Reference 
to  software  documentation  are  through  the  assigned  AFV  software 

configuration  control  number. 

5.12.2.2  Corresoondgnce  Traceability 

Correspondence  traceability  requires  that  the  documents  be  organiceo  :  r, 
such  a  manner  that  the  topics  listed  in  the  table  of  contents  of  a 
predecessor  document,  except  for  major  paragraph  headers  already 
established  in  Data  Item  Descriptions  (DID's),  are  duplicated  m 
s-ubsequent  documents  with  additional  levels  of  detail  prcviced. 

Cor r esbonaenr p  traceability  provides  a  means  c*  correlatinq  test 

spec  1 1  cat  1  on  and  test  procedures. 

5.12.T  ‘.amine  Conventions 


Naming  conventions  applied  in  high  level  documents  to  programs,  functions, 
data  elements,  etc.  shall  remain  unchanged  in  subsequent  documentation, 
except  for  the  number  of  characters  allowed  when  such  information  is  found 
in  the  program  listing.  This  consistent  naming  policy  provides 
traceability  between  the  documents  generated  at  varin^is  stages  c-*  t^e 
software  development. 
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5.12.4  Software  Documentation 

The  -following  documents  shall  be  prepared  as  part  o-f  the  AFV  so-ftware 
development  program: 

o  So-ftware  Development  Plan  (SDP) 

o  Software  Design  Specification  (SDS) 

o  Software  Requirements  Specification  (SRC) 

o  Software  Product  Specification  (SPS) 
o  Software  Top  Level  Design  Document  (STLDD) 
o  Software  Test  Reports  (STR) 

o  Software  Test  Plan  (STP) 

0  Software  Test  Procedures  (3TPR) 

Q  Version  Description  Documents  (VDD) 

0  Computer  Resources  Integration  Support  Document  (CRISD) 
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5. 13  CONFIGURATION  MANAGEMENT  PLAN 

This  plan  addressed  the  Implementation  o-f  the  configuration  management 
discipline  -for  software  documents.  Software  control  shall  conform  with 
applicable  military  standards  including.  MIL-BTD-483A,  MIL-STD-490A ,  and 
MIL-STD-1679. 


Computer  Program  Configuration 


The  fundamental  unit  for  control  is  the  Computer  Program  Configuration 
Item  (CPCI)  as  defined  by  MIL-STD~483A. 


Software  Configuration  Management 


Specific  responsibilities  of  the  Software  Configuration  Management 
Function  are: 


0  Prepare  and  maintain  a  configuration  management  plan  which  will  be 
the  basis  for  configuration  management  performance  during  the 
program. 

o  Prepare  and  publish  specific  methods  as  necessary  in  order  to 
accomplish  the  program  objectives. 

o  provide  directicn  concerning  reouirements  *  or  c  on*  i  cur  at  i  c^: 

Identification. 

o  Provide  direction  and  guidance  for  the  preparation  of  CPCI 
specif  1  cat . ons. 

o  Allocate,  through  utilisation  of  a  specification  tree  method,  the 
criteria  of  the  reguirements  and  determine  that  the  intent  of  the 
requirement  specification  is  achieved. 

o  Assist  development  engineering  in  providing  specification  change 

notice  (SCN)  and  specification  development  records. 
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o  Provide  direct  and  positive  control  o-f  engineering  changes 
af-fecting  so-ftware.  This  requires  the  establishment  and 

administration  o-f  a  -formal  change  control  board  and  submittal  for 
approval  when  applicable, 
o  Conduct  formal  configuration  audits. 

o  Identify  and  maintain  baseline  configuration  identification  and 
status  accounting  data.  This  includes  both  contractual  data  (such 
as  engineering  cnanges  and  specification  cnanges  and  specification 
change  notice  status)  and  software, 
o  Review  and  approve  test  report. 

5.14  SOFTWARE  DEVELOPMENT  APPROACH 

Tne  software  development  methodology  for  the  AFV  shall  be  a  top-aown 
structured  approach  for  producing  and  testing  software.  Predominant 
cnar acter 1 sti cs  of  the  software  development  shall  be:  use  of  HOL  (Ada); 
top-down  design;  program  modularity;  periodic  reviews;  and,  phased, 
top-down  integration  and  testing.  Ada  PDL  shall  be  utilized  for  the 
design  of  the  system  development  software.  The  Ada  PDL  shall  conform  in 
Its  s /nta;;  and  semantics  with  the  Ada  language  as  specified 
ANS I  I L-'STD- 1 8 15A .  This  human  readable  and  macnme  processacle  snai.! 
ce  .'sed  to  ccmmLinicate  design  decisions  amonc  software  revel  oomeri  t 
cerscnnel  and  to  facilitate  early  identification  of  design  errors. 
software  cevelooment  process  can  be  divided  into  tne  following  phases: 
planning,  requirements  definition  (system  specification),  analysis, 
preliminary  design,  detailed  design,  coding  (implementation),  unit 
testing,  CSC  integration  and  testing,  CSCI  testing,  system  integration  and 
testing,  and  operational  testing  evaluation  of  the  engineering  life 
cycle.  Planning  phases  are  discussed  below. 
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5. 15  SOFTWARE  REQUIREMENTS  DEFINITION  PLAN 

A  success-ful  software  development  program  begins  with  a  detailed,  well 
thought-out  requirements  definition.  The 

allocation  of  fundamental  requirement  to  Computer  Program  Configuration 
Items  (CPCI)  shall  be  based  upon  a  thorough  analysis  of  total  system 
requirements  and  may  require  simulation  studies  and  processor /host  system 
research.  A  systematic  study  of  data  transfer  requirements  for  the 
proposed  architecture  shall  be  made  to  determine  data  transfer  rates  that 
are  at  such  a  rate  that  will  meet  requirements  for  each  subsystem 
element.  Test  requirements  shall  al -o  be  generated.  This  phase 

culminates  in  the  formulation  of  a  development  specification  for  each 
CPCI. 


5.16  SOFTWARE  DESIGN  '='LAN 


The  software  design  pnase  allocates  CPCI  requirements  as  soecified  in  the 
development  speci f i cati ons  to  fundamental  components  and  then  to  the 
comoilation  unit  level.  The  objective  is  to  formulate  a  design  that  meets 
performance  objectives,  is  mcdulariced  to  allow  shared  resoonsi d i 1 i t v  in 
the  1  mol ement at  1  on  phase  and  adaotability  to  design  cna-ces,  and  is 
p^ccu.cible  and  testaale  ^.tii  icing  an  incremental  imclenentatior, ,  test,  arc 


5.16.1  Aoa-Based  ^'rocram  Desicn  Lanauaae 


The  AFV  software  shall  De  designed 
Language.  The  PDL  shall  be  used 

saecif ications. 


using  Ada-based  Program  Design 
to  generate  both  B-5  and  C-5 
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5. 17  SOFTWARE  IMPLEMENTATION  PLAN 

The  objectives  oi  this  AFV  so-ftware  development  phase  are  to  design  and 
code  compilation  units  (CU)  and  have  each  CU  success-fully  pass  subprogram 
testing.  Preparations  o-f  subprogram  tests  shall  be  made  in  parallel  with 
CU  coding.  Walk  throughs  shall  be  held  to  veri+y  that  each  CU  conforms  to 
programming  standards,  satis-fies  the  requirements  and  implements  the 
design  in  the  B-5  speci-f ication.  Test  procedures  shall  be  reviewed  to 
determine  proper  re-flection  o-f  B-5  test  requirements  and  to  veri-fy  an 
adequate  -functional  te>:t. 

5.18  SOFTWARE  INTEGRATION 

AFV  sQ-ftware  shall  be  done  in  a  top-down  manner  in  an  environment  that  as 
closely  as  possible  resembles  real  world  operational  conditions. 
Integration  tests  are  needed  to  veri-fy  operations  o-f  the  AFV  CPU  and  it  s 
software  modules,  and  to  ensure  that  the  software  units  interface  properly 
and  conform  to  the  corresponding  design.  This  testing  demonstrates  that 
the  control  and  data  flow  between  units  is  properly  maintained,  that  all 
units  and  stubs  are  present  and  that  the  unit  is  sufficiently  stable  to 
permit  functional  requirements  testing. 

5.19  SOFTWARE  TESTING  AND  EVALUATION  PLAN 


The  purpose  of  AFV  software  testing  shall  be  to  evaluate  the  performance 
of  this  software  in  meeting  the  system  requirements.  Testing  shall  be 
planned  and  executed  for  the  purpose  of  providing  a  formal  basis  for 
program  performance  evaluation.  The  test  documents  shall  reflect  a 

top-down  approach  to  testing  that  is  carried  throughout  testing, 
integration,  and  retest. 


5.25 

XV-V-25 


UNCLASSiFiED 


-/-/-As*  nV  A-n. 


%  N  •« 


--  Vv* 


AFV  CRMP 
VOLUME  XV 


JNCL.ASSIFIEO 


1  SEPTEMBER  87 
DEVELOPMENT  MANAGEMENT 


5.19.1  Test  requirements  are  generated  simultaneously  with  design 
requirements.  Test  requirements  are  re-fined  continuously  throughout  the 
design  cycle  from  initial  system  level  design  down  to  compilation  unit 
design.  Types  of  testing  used  shall  include:  subprogram  (CU  level) 
tests,  integration  tests,  and  functional  requirements  tests. 


5.19.2  Subprogram  test  are  also  known  as  unit  design  qualification, 
these  tests  shall  demonstrate  that: 


o  The  CU  compiles  with  our  errors. 

o  The  correct  flow  of  control  occurs  through  a  CU  with  e>;ecutable 

code. 

o  The  proper  numerical  results  are  oDtained  from  a  CU  containing 

calculations. 

o  Tne  calculations  within  a  CU  meet  the  relevant  requirements  for 
stability,  convergence,  scaling,  ana  range. 

5.19.3  When  a  group  of  CUs  have  oassed  subprogram  tests,  integration 
tests  oegin.  Integration  testing  verifies  correct  data  intercnange 
cetween  CUs  witnin  a  CPCI  and  also  among  CPCIs  within  the  entire  svsteTi. 

5.19.4  A^ter  tne  interfaces 
•'u.ncticn al  regui  recent s  begins, 
soec  1  1  c at  1  cns  are  then  tested, 
conolete  checkout  of  tne  proposed 

5.19.5  Operational  software  shall  be  verified  over  the  complete  AFV 
operational  envelope.  In-operation  fault  detection  software  shall  be 
verified  by  introducing  faults  into  various  subcomponents,  sensors,  and/or 
actuators,  one  at  a  time.  Performance  following  the  introduction  of  these 
faults  will  be  monitored  to  demonstrate  that  requirements  are  being  meet. 


have  Deer  crcperly  verifieg,  testin-  : 

^■0  QUl  r  9(715"  t=  HI  5- It  13^  t*"5  C  =  V5:CI.'^5“ 

Tne  tests  snrll  De  re 

archi  tect'jre. 
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Design  -facilities  include  word  processors,  Program  Design  Languages  (PDL)  , 
and  their  associated  hosts,  personal  computers,  etc.  Host  computer 
■facilities  include  so-ftware  development  tools  such  as  compilers, 
assemblers,  linkers,  printers,  platters,  etc.  Host  -facilities  may  be 
large  main— frame  computers,  or  more  pre-ferably,  the  smaller  microcomputer 
that  can  programmed  using  sel-f-contained  Micro  Development  Programs.  The 
■following  guidelines  should  be  followed  in  the  selection  of  the  host 
facilities  for  the  AFV  software  development  effort: 


o  Availability  of  a  reliable  Ada  comoiler. 

o  Maturity  of  the  compiler.  Debug  of  compiler  problems  anc  cne 

work-around  required  car,  be  costly, 
o  Availability,  mainta.inabi  1  ity,  ana  cost  of  peripneral  s. 
o  Target  processor  selection.  Host  compiler  must  produce  object 

code  of  target  processor. 
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5.20.2  Target  Processor 

In  selection  o-f  a  target  processor,  a  care-ful  balance  must  be  maintained 
betk^een  cost,  size,  and  weight  -factors,  and  the  memory  and  throughput 
requirements  imposed  upon  the  processor  by  the  AFV  system.  So-ftware  costs 
escalate  exponentially  as  memory  utilization  nears  capacity.  Good 

so-ftware  design  can  protect  critical  functions  from  degrading  when 
throughput  demands  exceed  machine  capability. 

5.20.3  AFV  Processor  Selection  Guidelines 

o  Ada  compiler  targeted  to  the  processor, 
o  Capability  for  handling  throughput, 

o  Sufficient  memory  capacity, 

o  Cost,  size,  and  weight  factors, 
o  System  archi tecture/bus  compatibi 1 i ty. 
o  Software  loading  methodology, 
o  Test  support  facilities. 

5.21  ENGINEERING  PRACTICES 


Tne  Cesign  approach  will  stress  hierarcnical  :-cs-e-cs":=  z* 

comporenzs  ;loa5e  coupling),  modularity,  anp  zl?rit.  - 1  s-- :  z-'-.sit :  z' s  . 

Dczumentati  on  will  stress  traceability  o-f  sz-t.-.a-'s  =zaz;  - .  zati  z"  s  zz 

actual  testing,  formal  standards,  clarity  of  descr i pt i zns ,  ang  easily 

readable  listings.  Testing  will  stress  formal  demonstrations  of  mission 

requirements  and  use  formal  error  data  collection  methods.  The  following 

software  engineering  practices  and  standards  will  pe  used  in  the 

,  development  and  maintenance  of  the  AFV  software, 

i 

5.21. 1  Quality  Assurance  Practices 

To  ensure  quality,  the  developers  shall  employ  approved  C-oality  Assurance 

contractor  practices  or  substitute  Government  approved  equivalent 

practices  which  could  include  the  followmo: 
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Structured  Design 

Top  Down  Development 

Chief  Programmer  Team 

Formal  Standards  and  Guidelines 

Data  Item  Index 

Hiercharchy  plus  Input/Process/Output 
Structured  Programming 

Unit  Development  Folders  w/automated  assistance 
Structured  Walkthroughs 
Programming  Support  Library 
Formal  Error  Data  Collection 


5.21.2  Standards  and  Conventions 


The  standards  and  conventions  affecting  the  AFV  development  effort  are 
specified  in  appropriate  sections  of  the  Statement  of  Work  and  the 
Contract  Data  Requirements  List.  They  provide  specific  detailed  guidance 
•^or  procedures,  design,  program  structures  and  conventions,  display  and 
logic  standaras,  and  I/O  signal  standards.  They  include: 


Specification  stanoards 
DocL'.T.entati  on  standaros 
Frngr-?r.'7ii  r  g  standards 
C'ualit/  Assurance  standards 
Configuration  Management  standards 
Testing  standards 


5.21.3  Development  Procedures 

The  software  engineering  practices  that  are  employed  in  the  development  of 
the  AFV  software  are  described  in  DOD-STD-2167.  Monitoring  and 
enforcement  of  the  practices  will  be  accomplished  by  the  management 
procedures  presented  in  Chapter  2  of  the  CRMP.  The  engineering  practices 

v/w  V/  on 


that  will  be  used  are: 


XV-V-29 


AFV  CRMP 
VOLUME  XV 


!  I  i  I  —  'v 

lii"L/U5;:)ir!rO 


1  SEPTEMBER  87 
UEVELOPMENTT  MANAGEMENT 


So-ftware  Tool  Development  Environment 

Structured  design 

Top  down  design 

Functional  diagram 

So-ftware  development  -files 

Structured  walk  through 

Formal  ieat  methooalogy 

So-ftware  update  procedure 

Data  Item  index  and  cross  re-ference 

Supportacle  data  structures 

Communication  Integration 


S.21.4  Common.  Standard,  and  Feusabie  So-ftware  Comconents 


Maximum  use  o-f  common,  standard,  and  reusable  sc-^tware  components  i 
mandatory.  Tne  A^VTF  will  be  responsible  -for  the  establishment  an 
function  of  a  standard  software  review  comm.ittee  under  the  autcmiatio 
communi cati on  resource  working  group  (ACRwG’  for  the  purpose  c*  evaluatin 


sp-^  tv.ar  e 


The  ACRwS  mav  '•eoommend  a  standard  so-^twa,' 


The  AFV  security  classification  guide,  (to  be  developed),  will  include  A^V 
software  security  reaui rements .  Material  covered  in  the  guide  may  e---*ect: 

0  Computer  Software  Programs 
o  Data  Base 

o  Data  Storage 
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Access  Control 
TEMPEST  Requirements 

Declassi-f ication  Techniques  and  Control 

Data  Links 

Document  Control 

COMSEC  and  OPSEC  Requirements 


5.23  INTERQPERABILI'^Y  AND  INTERCHANGEABILITY 

5.23.1  Army  Command  ana  Control  Svstem  (ACCS)  Interooeraoi 1 i ty 

The  reouirements  ior  the  AFV  automation  and  communications  resources  are 
based  heavily  on  B2C2  systems  and  on  the  Fighting  Vehicle's  internal 
control  requirements.  The  requirements  are  also  based  on  the  need  to 
communicate  with  ACCS  components.  Interoperability  ot  protocols,  data 
components,  and  -formats  between  the  AFV  and  ACCS  components  tall  mission 
areas)  is  required. 

5.23.2  U.3.  Navy  and  Air  Force  Interooerabi 1 i tv 


VC.JT9 


Requirements  Review  or  A5ARC  Documentation.  It  is  intenoed  that  tne  AFV 
automation  and  communications  resources  be  i nterooerab 1 e  to  tne  maximum 
degree  possible  commensurate  with  AFV  acquisition  schedules  and  with 
National  interests.  Applicable  NATO  standards  shall  be  met  when  possible. 
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5.23.4  Vehicle  Interchangeabi 1 i ty 

APV  vehicle  subsystem  interchangeability  is  base  on  two  levels  o-f 
commonality;  -family  and  chassis.  Family  commonality  re-fers  to  AFV  wide  or 
universal  commonality.  Chassis  commonality  re-fers  to  the  components  or 
subsystems  common  to  a  particular  AFV  weight  class.  Family  common 
command,  control,  communications  ;C4)  and  electrical  subsystems  shall  be 
lOOV.  1  ntercha.ngeabl e  due  to  the  modular  design  o-f  the  AFV.  Chassis  common 
subsystems  will  also  oe  lOOV.  interchangeable.  Interchangeability  goals 
-for  an  AFV  mission  module  unique  components  will  be  determined 

5 . 24  SIMULATION  TECHNICUES  AND  REQUIREMENTS 

To  the  greatest  e;:tent  possible,  operational  C4  and  electrical  system 
mock— uos  will  be  developed.  Tne  minimum  objective  is  to  determine  or 
confirm  the  human  -factors  engineering  analysis  -for  physical 
con-f  1  gurati on .  The  Maximum  objective  is  to  validate  the  inter-face  and 
interconnection  o-f  C4  and  electrical  system  components  or  subsystems. 
Simulation  will  be  used  to  determine  the  force  level  effect  of  AFV  C4 
components. 


Oevel cpment  of  a-.-tomation  and  communi cati c-ns  -esources  for  tr.e  A-v'.  Wmle 
Chapter  5  follows  DCD  standards  for  documentation  it  also  imposes 
management  organizations  not  normally  used  for  the  develooment  of  computer 


resources 
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CHAPTER  6  -  TEST  AND  EVALUAT I  ON 


6. 1  INTRODUCTION 

This  Chapter  o-f  the  CRMP  addresses  the  management  o-f  the  test  and 
evaluation  o-f  the  Armored  Family  o-f  Vehicles  (AFV)  computer  resources.  It 
presents  the  plan  and  schedule  -for  development  o^f  test  plans  ■for  testing, 
ver  1 -f  1  cat  1  on ,  and  validation  o-f  the  automation  and  communications 
resources  -for  the  AFV. 

6.1.1  Testing  Goal 

The  goal  and  explicit  purpose  o-f  computer  resource  testing  is  to  determine 
failure.  Failure  is  defined  as  the  determination  that  an  error  exists  in 
system  requirements,  specifications,  design,  programs,  equipment  or 
testing  methodology.  The  vast  nature  and  complexity  of  AFV  computer 
resource  applications  demonstrates  that  1007.  testing  is  impossible.  The 
myriad  of  possible  combat  scenarios,  soldier  operations,  and  sensory 
inputs  prevents  total  testing.  Therefore  each  piece  of  the  vehicular 
electronics  must  be  tested  separately  and  in  various  combinations.  System 
integration  testing  methodologies  that  can  assure  selected  levels  of 
testing  will  require  further  refinement. 

6.1.2  Testing  Policy 

Deployment  of  a  system  implies  that  sufficient  testing  has  been 

accomplished  to  assure  that  the  system  satisfies  its 
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speci-f ications/requirements  and  is  per-forminq  as  designed.  All  changes 
must  also  undergo  su-f-ficient  analysis  and  testing  to  ensure  that  system 
quality  and  -functions  are  preserved.  Designated  test  agencies  will 
coordinate  with  TRADOC,  AMC,  and  other  proponent  agencies  to  determine  the 
degree  and  method  of  testing  required  for  each  AFV  system  modification. 

6.1.3  Test  and  Evaluation  Master  Plan 

The  Test  and  Evaluation  Master  Plan  (TEMP),  published  separately, 
addresses  the  approach  and  methodology  of  testing,  the  objectives  of  the 
testing,  the  resources  required,  the  responsibilities  and  interaction  of 
the  involved  agencies  and  commands,  and  the  purpose  and  function  of  the 
Test  Integration  Working  Group  (TIWG) .  A  Test  and  Evaluation  Master  Plan 
(TEMP)  shall  be  prepared  separately  by  the  chair  of  the  TIWG  in  accordance 
with  AR  70-10,  and  in  conjunction  with  the  other  members  of  the  TIWG  (See 
Figure  6-1),  The  TEMP  will  identify  the  test  plans,  testing,  and  schedule 
for  the  technical  Development  Testing  (DT)  and  user  Operational  Testing 
(OT)  of  the  AFV,  It  will  identify  the  test  concepts  and  the  critical 
issues  which  must  be  addressed  for  the  AFV.  As  a  minimum,  the  TEMP  will 
incorporate  the  following; 

o  ’’est  will  not  be  repeated  if  satisfactory  results  can  oe  obtained 
through  othei^  test  efforts. 

o  A  orogram  will  not  move  to  the  ne;:t  pnase  or  project  objective 
until  all  significant  deficiencies  are  identified  and  corrective 
measures  are  planned. 

o  Developmental  Testing  ?<  Evaluation  (DT?<E)  will  verify  attainment 
of  technical  specifications  and  objectives, 
o  User  Operational  Testing  &  Evaluation  (0T?<E)  will  assess  the 
system's  operational  effectiveness  and  suitability. 
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o  Testing  and  nondevelopinent  items  will  be  production  tested  to 
insure  compliance  with  contractual  requirements, 
o  Organizations  having  logistics  and  user  responsibilities  will 
participate  in  the  test  program. 

o  Test  cycles  will  be  coordinated  to  minimize  resource  needs, 
prevent  duplication,  and  maximize  data  yield. 

6.1.4  TEMP  and  CRMP  Evaluation 

The  goal  o-f  the  TEMP  is  to  provide  managerial  guidance  concerning  the 
entire  AFV.  This  section  o-f  the  CRMP  focuses  on  automation  and 
communication  resource  testing.  Consistency  between  the  Test  and 
Evaluation  (TEMP)  and  C Communication I  Computer  Resource  Management  Plans 
must  be  maintained.  Organizations  identi-fied  in  Chapter  3  are  responsible 
•for  TEMP  and  CRMP  review  to  ensure  consistency  is  maintained. 
Inconsistencies  and  recommendations  must  be  immediately  reported  to  the 
CRMP  AFV  point  o-f  contact  identi-fied  in  Chapter  1. 

6.2  TEST  ORGANIZATION  AND  RESPONSIBILITIES 

6.2.1  Organization 

The  organizations  and  agencies  that  are  responsiole  -for  the  test  and 
evaluation  o-f  AFV  so-ftware  and  hardware  are  de-fined  in  paragraph  6.2.2. 
These  activities  per-form  varied  roles  during  the  development  and 

operational  test  phases  and  must  cooperate  as  team  players  to  assure  the 
success  o-f  the  Test  and  Evaluation  Master  Plan.  Following  -further  -full 
scale  development,  this  section  will  be  expanded  to  include  the 

i  denti -f  i  cation  o-f  those  organizations  responsible  for  independent 

verification  and  validation  of  software.  The  current  procurement 
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philosophy  precludes  their  being  identified  at  this  phase  of  AFV 
development. 

6.2.2  Resoonsibi 1 ities 

The  Director,  AFVTF  has  overall  responsibility  for  assuring  that  the  Test 
and  Evaluation  Master  Plan  is  successfully  executed.  Primary  test 

coordination  will  be  accomplished  through  the  TIWG  and  ACRWG.  Specific 
responsibilities  of  the  organizations  aepicted  in  Figure  6-1  will  be 
incorporated  upon  publication  and  approval  of  the  preliminary  AFV  TEMP. 

6.2.2. 1  AFV  Task  Force.  The  Director,  AFVTF  manages  the  TEMP  as  set 
forth  in  the  TEMP  and  supplemented  in  this  Chapter  of  the  CRMP. 

6. 2. 2. 2  Test  Integration  Working  Group  (TING).  Chaired  by  the  AFVTF 
Deputy  Director  for  Combat  Development,  the  TIWG  provides  a  forum  for 
direct  communication  to  facilitate  the  integration  of  test  requirements 
and  to  speed  the  TEMP  process.  The  TIWG  will  define  the  responsibilities 
and  1 nterrel at  1 onshi os  of  the  materiel  developer,  combat  developer, 
logistician,  trainer,  developmental  and  operational  testers  ana 
evaluators,  LC3EC,  and  other  concerned  organizations  during  the  various 
levels  of  software  testing.  The  organization,  puroose,  and  activities  c* 
the  “^IWG  are  contained  in  the  AFV  TIWG  Charter  which  will  pe  incG''co.''at0d 
as  an  Anne:;  to  the  TEMF’  when  aoproved  and  oublisned. 

6.  2.  2. 3  Automation  and  Communcation  Resource  Wort- mg  Group  'ACRwG' 

Review  Appendix  C,  Charter  for  the  ACRWG  and  Chapter  3,  Program 

Management . 
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Army  Materiel  Command  (AMO 


Trainina  and  Doctrine  Command  (TRADOC) 


Operational  Test  and  Evaluation  Agency  (OTEA) 


Tank  and  Automot: ye  Command  (TACOM) 


S'.'Htems  wnalvsia  Activitv 


Communication  and  Electronics  Command  (CECOM) 


Program  E>:ecutive  Q-f-^icer 
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Test  and  Evaluation  Master  Plan  Organization 


System  Details 

1.  Mission  Description 

2.  System  Description 

3.  Required  Technical  Characteri sti cs 
Program  Summary 

1 .  Management 

2.  Integrated  Schedule 
Developmental  Testing  ?<  Evaluation  Outline 

1.  Critical  Technical  Character i sti cs 

2.  DTtxE  to  Date 

3.  Special  Requirements  -for  System/Subsystem  Retest 

4.  Future  DT?/.E 

Operational  Test  ?<  Evaluation  Outline 

1.  Critical  Operational  Issues 

2.  0T5<E  to  Date 

3.  Future  QT?<E 

Test  and  Evaluation  Resource  Summary 

1.  Test  Articles 

2.  Test  Sites  and  Instrumentation 

3.  Test  Support  Equipment 

4.  Threat  Systems 

5.  Test  Targets 

6.  Operational  Force  Test  Support 

7.  Simulators,  Models,  and  Testbeds 

8.  Special  Requirements 

9.  T?tE  Funding  Requirements 

10.  Resource  Schedule 

11.  Manpower/Traini ng 
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6.2.2.10  Contractors.  Contractors  will  be  responsible  -for  actual 
per-formance  o-f  the  major  portion  o-f  Developmental  Test  and  Evaluation 
(DT.!v,E)  to  demonstrate  compliance  o-f  the  computer  so-ftware  programs  with 
the  computer  so-ftware  development  speci-f icati on  o-f  the  AFV  with  the  system 
specification.  Contractors  will  also  be  responsible  -for  providing  all 
comouter  resources  and  related  support  facilities  necessary  for 
accomplishing  the  DT.VE  of  the  AFV  software.  Contractors  may  be  required 
to  provide  selected  computer  resources  and  related  support  facilities  for 
Operational  Test  and  Evaluation  (0T?<E). 

6.2.2.11  System  Integrator.  The  system  integrator  will  be  responsible 
for  software  validation,  verification  and  testing  of  comouter  software 
components  in  the  AFV  during  DT’vE  and  will  provide  computer  software 
testing  support  during  GT^/E.  The  testing  of  computer  software  components 
at  the  integrated  level  will  include  software  component  interfaces  to 
internal  AFV  functions  such  as  weapons  systems  and  external  interfaces  to 
battle  management  functions  such  as  communications.  The  integration 
contractor  will  construct  and  maintain  a  AFV  computer  resources  prototype 
*or  use  by  contractors  during  DT?<E.  Control  ana  management  responsibility 
of  the  comouter  resources  prototype  will  pass  to  the  AFV  LGSEG’.s)  at  tne 


Spec  1  cat  1  chis  will  Pe  tested.  The  goal  of  soec  i  f  i  cs  1 1  on  testing  is  to 
determine  specification  errors  prior  to  programming  or  hardware 
development.  Algorithms  specified  m  the  specification  documents  will  be 
thoroughly  analyzed.  The  ultimate  goal  of  this  analysis  is  to  achieve  a 
best  possible  rigorous  proof  of  specification  algorithms. 
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6.4  COMPUTER  HARDWARE  TESTING 


Hardware  testing  requirements  have  not  been  -fully  developed  at  this  time. 
However,  for  planning  purposes  hardware  testing  schedules  should  coincide 
with  software  testing. 

6.5  SOFTWARE  TESTING  METHODOLOGY 

Plans  will  be  developed  for  testing  compliance  of  the  specification  for 
each  software  requirement  and  applicable  interface  requirement.  The 
testing  approach  will  be  in  conformance  with  the  Test  and  Evaluation 
Master  Plan  (TEMP).  Software  test  planning  will  include  both  formal  and 
informal  tests. 

6.5.1  Formal  Testing 

Formal  tests  will  be  developed  for  each  software  requirement  and  for  all 
critical  software  components  and  interfaces  which  represent  an  area  of 
risk  within  the  system.  Formal  tests  will  include  stress  scenarios,  such 
as  capacity  tests  and  error  handling  conditions.  Formal  tests  will 
require  Government-approved  test  descriptions  and  prcceoures,  will  oe 
witnessed  by  the  Government  or  a  Government-designated  representative,  and 
will  be  documented  by  a  test  report  for  Government  approval. 

6.5.2  Informal  Testing 

Informal  tests  are  internal  contractor  development  tests  conducted  during 
coding  and  unit  testing  and  specification  integration  and  testing. 
Informal  tests  will  address  and  demonstrate  the  correct  functioning  of  all 
software  components  under  realistic  loads,  the  proper  and  complete 
allocation  of  all  software  functions,  and  the  correct  implementation  of 
specification  interfaces.  Although  test  descriptions,  procedures,  and 
reports  for  informal  tests  do  not  require  government  approval,  they  will 

be  documented  by  the  contractor  and  made  available  for  Government  review. 
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6.5. 


Testing  Requirements 


i: 


The  objective  o-f  the  so-ftware  testing  e-f  +  ort  is  to  ensure  that  each  new 
version  o-f  a  computer  program  distributed  to  the  deployed  system  is 
correct  and  -ful-fills  the  associated  operational  requirements.  Tne 
Software  Testing  activities  o-f  the  AFV  LCSEC  will  be  conducted  as 
descrioed  below.  Deviations  -from  these  policies  will  be  made  only  with 
the  written  approval  of  the  Chief,  LCSEC. 


6.5.3  Test  ^'equi  rements  Analysis 


Computer  program  functional  requi rements ,  including  acceptance  criteria, 
I  will  be  specified  m  the  Computer  Program  Development  specifications  and 

the  requirements  for  qual i f ication  test  will  also  be  specified. 
Contractor  analysis  of  these  functional  requirements,  acceptance  criteria, 
and  qualification  test  requirements  will  be  the  basis  for  generating  the 
[  Qualification  Test  Plan  and  associated  test  schedules.  This  analysis  will 

also  enable  the  contractor  to  determine  the  test  tools  and  simulation 
models,  and  their  ac oui si t i on/devel opment  schedules,  needed  to  support 
both  qualification  test  and  engineering  Development  tests. 

I 


6.5. P  ""est  ^Ta.ns  -  The  System  Test  ^  1  an  will  include  definition  o-^  tne 
requirements  for  tests  to  demonstrate  that  tne  cevelooed  software  meets 
all  Software  Deveiooment  Specification  requirements.  Tne  test  plan  wi . 1 
describe  locations,  schedLiles,  and  limitations  of  tne  tests:  preoaratio'’ 
of  input  data;  methods  for  analyzing  results;  and  requirements  for 
equipment,  support,  software,  and  personnel. 

6.5.5  Test  Planning 


The  AFV  LCSEC  (or  AFVTF  designee)  will  determine  the  scope  of  testing 
required  to  ensure  that  the  software  modifications  made  meet  all  specified 
technical,  operational,  and  performance  requirements  and  the  acceptance 
criteria.  Test  planning  will  include  development  of: 
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o  So-ftware  acceptance  criteria  at  each  level  of  testing 

o  Specific  objectives  at  each  level  of  testing 

o  Internal  procedures  for  scheduling  and  conducting  tests 

o  Detailed  procedures  for  conducting  testing 

o  Procedures  for  reporting  test  results, 

o  Specification  and  Design  testing. 

All  test  plans,  specifications,  and  procedures  will  be  subject  to  the 
review  and  approval  of  the  AFV  designated  LCSECs. 

6.5.6  Levels  of  Software  Testing  Required 

The  AFV  LCSEC  will  test  all  software  and  software  changes  which  it 
produces  and  ensure  that  each  aspect  of  the  software  is  thoroughly 
exerci sed. 

6.5.7  Programming  and  Unit  Testing 


Programming  and  unit  testing  includes  testing  accomplished  during  actual 
programming  of  a  software  program  or  unit  and  it  includes  testing  of  the 
unit  according  to  design  and  to  performance  within  a  system. 

6.5.7. 1  P-oor ammi nq  -  During  this  activity,  the  detailed  design  will  De 
translated  into  program  code  and  data  definitions,  and  the  resulting  units 
of  code  will  be  tested.  The  AFVTF  will  carefully  monitor  contractor 
progress  using  quantitative  and  qualitative  measures  of  progress, 
especially  when  coding  spans  an  extended  period  of  time  or  when  a  large 
amount  of  code  is  being  developed. 


6.5. 7. 2  Programmer  Unit  Testing 


Unit  Level  testing  is  the  responsibility  of  the  programmer.  Prior  to  unit 
level  testing,  a  code  walk-through  will  be  conducted  by  the  project 
engineer  responsible  for  that  software  product.  As  a  minimum,  unit  level 
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testing  will  be  per-formed  to  ensure  warning  or  error  -free  compilation  and 
assembly  of  the  coded  unit,  to  ensure  that  the  coded  unit  -fully  satisfies 
the  detailed  performance  and  design  requirements,  to  ensure  that  input  and 
output  expectations  are  met,  and  to  ensure  that  all  code  delivered  has 
been  fully  exercised. 

6. 5. 7, 3  Unit  Level  Testinq  -  Unit  testing  is  part  of  the  informal 
whitebox  testing  program.  Before  beginning  unit  testing,  test  procedures 
for  unit  testinq  shall  be  defined.  Government  approval  of  these  test 
procedures  is  not  required.  Unit  testing  shall  exercise  individual 
software  units  to  check  for  agreement  with  detailed  design,  correct 
execution,  and  proper  data  handling.  The  objectives  of  unit  testing  are 
to  assist  in  the  development  of  the  specifications  for  each  software 
requirement,  to  provide  visibility  into  the  progress  of  the  development, 
and  to  prepare  for  formal  testing. 


6.5. 7. 4  Black  Box  Testinq.  -  Unit  level  testing  will  consist  of  formal 
black  box  tests  to  verify  that  each  function  of  the  unit,  or  aggregate  of 
units  satisfies  the  Software  Requirements  and  applicable  Interface 
Requirements.  Formal  testing  will  be  per-^ormed  in  accordance  with  the 
STP,  STD,  and  Software  Test  Procedures  (STPR).  "ormal  testing  is  a 
orimary'  criteria  for  determining  system  acceotance:  tne’^e-^ore,  orior 
in-^ormal  testing  results  will  not  be  used  in  place  of  ■‘ormal  testing.  =3’' 
those  mcdL.ies  (sL;cn  as  a  utilit/  program)  which  are  relative!  /  1 "  se'"  si  1 1  .-e 
to  system  operation,  formal  testing  may  be  conducted  at  the  developer  5 
facility.  For  large  operational  modules,  the  comolexity  of  the 
performance  requirements  may  require  additional  testing  usin-  the 
integration  contractor  computer  software  prototype  or  during  later  DT?,E  or 
OT&E.  The  AFV  PMO  will  assiduously  monitor  contractor  progress  to  assure 
performance  meets  all  aspect  of  the  STD,  STP,  and  the  STPR. 
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6.6  SOFTWARE  STRESS  TESTING 


The  Software  Stress  Test  will  exercise  all  -functions  o-f  the  so-ftware  -for  a 
period  of  time  in  order  to  demonstrate  that  the  software  is  free  of 
serious  or  numerous  errors.  Under  this  test,  the  software  is  to  be  tested 
to  the  limits  of  its  designed  capacities  and  beyond,  in  order  to  ensure 
that  degradation  at  the  point  of  saturation  is  not  catastrophic.  Methods 
of  stressing  the  software  shall  include,  but  are  not  limited  to: 

o  Provide  more  information  to  be  processed  than  the  processor  is 

designed  to  accommodate. 

o  Saturate  the  data  transfer  capabilities  by  requiring  more  data  to 
be  transferred  in  and  out  of  memory,  peripherals,  subsystems,  and 
interfacing  systems  than  the  system  was  designed  to  accommodate. 

0  Provide  zero  input  for  processing-  to  assist  m  null  condition 

processing. 

o  Exceed  assigned  storage  are  capacities,  e.g.,  buffers,  tables,  and 
scratch  areas. 

6.6.1  Length  of  Stress  Testing 

The  length  of  time  of  this  test  will  vary  deoending  on  the  comole':itv 
the  program  and  mission  of  the  system  under  test.  Initial  system  setup 
time  to  establish  normal  operating  conditions  will  not  be  incluGefl  as  part 
of  the  test  period. 
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6.6.2  Stress  Testing  o-f  Continuausly  Operated  Systems 

For  systems  that  are  designed  to  operate  continuously  -for  more  than  one 
day  at  a  time  when  the  system  is  placed  into  operation,  the  minimum  length 
o-f  time  o-f  this  test  shall  be  25  continuous  hours. 

6.6.2  Stress  Testing  o-f  Periodically  Operated  Systems 

For  systems  that  are  not  designed  to  operate  continuously  or  -for  more  than 
one  day  at  a  time,  the  minimum  length  of  time  for  this  test  shall  be  the 
length  of  time  required  to  fulfill  the  system's  mission(s),  including  any 
periods  before  and  after  the  mission  period  or  the  length  of  time  it  takes 
to  complete  the  test  requirements,  whichever  is  longer.  The  testing 
period  shall  be  continuous. 

6.7  PREPARATION  OF  TEST  DESCRIPTIONS 

Test  Descriptions  will  define  the  methods  and  criteria  of  conducting  the 
individual  tests  identified  in  the  Software  Test  Plan  (5TP)  when 
published.  The  STP  will  also  identify  any  software  that  will  not  oe 
tested.  Each  test  case  will  be  defined  in  terms  of  assumot i ons .  inouts, 
expected  results,  and  evaluation  criteria.  The  test  oescr  i  oti  oi^s  ♦o’^m  tne 
basis  *or  subsequent  development  of  test  p^'ocecures.  Zesf' i  pt  i  f  s 


proiedures  *or  formal  tests  shall  reouire  bove’"nment  aopr: 


VC... 


tests  will  be  fully  defined  in  terms  of  the  procedui^al  steps  to  prepare 
for,  execute,  analyze  the  results  of,  and  document  that  test.  The  AFVTF 
will  carefully  monitor  contractor  performance  to  ensure  that  the  test 
procedure  addresses  all  aspects  of  the  previously  defined  STP  and  STD. 

6.3  COMMUNICATION  SYSTEM  TESTING  to  be  determined 
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6.9  AFV  C4  ARCHITECTURE  TESTING 

The  C4  and  electrical  system  testing  will  be  covered  in  the  Integration 
Testing  paragraph  o-f  this  Chapter. 

6.10  INTEGRATION  TESTING 

Integration  Testing  shall  not  begin  until  all  o-f  the  units  for  the 
computer  program  have  passed  unit  testing-  Integration  Testing  will 
include  at  least  the  following  events: 

o  Ensure  error  free  linkage;  of  the  units 

o  Ensure  that  the  computer  program  meets  the  detailed  performance 
and  design  requirements 

o  Exercise  the  computer  programs  input  and  output 

a  Ensure  that  the  program  can  properly  handle  and  survive  erroneous 
inputs. 

o  Levels  of  degraded  performance  to  ensure  system  operational 
performance  can  be  maintained  while  selected  modules  are 
non-operati onal . 

0  Data  and  voice  communci ation  can  be  achieved. 

o  Interface  and  interconnection  of  components  or  subsvscems  w.tn  tne 
AFV  common  bus  architecture. 
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6.  10.  1  So-ftware  Integration  and  Testing 


This  phase  will  successively  integrate  and  test  units  ot  code  and 
components  until  a  complete  software  system  is  built.  Integration  and 
testing  normally  begin  by  integrating  and  testing  the  highest  level 
software  units,  and  then  proceeding  to  successively  more  comprehensive 
levels  of  integration.  Informal  tests  will  be  conducted  to  verify  procer 
functioning  of  the  components  software  modules  prior  to  software  module 
level  testing.  Formal  tests  will  be  conducted  for  those  component 
function  which  are  critical  to  the  software  module  as  determined  by  the 
time  or  performance  requirements. 


6 . 10.2  System  Integration  and  Testing. 

Software  and  hardware  modules  will  be  successively  integrated  and  testec 
to  validate  that  the  complete  system  is  properly  integrated  and  satisfies 
system  reouirements.  System  testing  shall  focus  on  the  interaction  of 
hardware  and  software  modules  of  the  system,  under  nominal,  stress,  ana 


endurance  conditions. 


Methods  of  testing  these  inte'^acti  ons  will 


comprehensively  ensure  that  the  software  fulfills  system  requirements. 
System  testing  will  be  conducted,  using  the  operational  conf i gurat i cn  c' 
nearest  possible  equivalent,  in  accordance  witn  the  system-level  cc)’'tio'' 


the  tpyC'.  System  testing  mav  be 


shed  cn  t“e  ccmi-L.te^  sc- 


orctct'rpe  provided  by  the  s/stem  integrator.  -  a’'t  i  c  i  oat  i  cn  c. 
lCSES'si,  the  independent  evaluators,  and  the  user  in  svstem  testi 
strongly  recommended. 


6.10.3  Operational  Environment  Testinc 


The  system  will  be  integrated  with  other  systems  and  tested.  This  testing 
will  formally  qualify  the  system  to  ensure  that  it  functions  properly  in 
the  operation  environment.  Tests  will  emphasize  the  interoperability  of 
the  system  with  the  software  and  hardware  modules  of  interfacing  svstems 

that  exist  in  the  operation  environment. 
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6.11  DEVELOPMENTAL  TESTING  (DT) . 

Technical  DT  will  be  per-formed  prior  to  Milestone  III  or  equivalent  to 
ensure  that  engineering  is  complete,  that  all  signiticant  design  problems 
have  been  identified  and  solutions  to  these  problems  are  in  hand,  and  that 
the  system  is  ready  for  user  OT.  DT  encompasses  all  computer  software  and 
specification  testing,  hardware/  software  system  level  testing,  and  system 
integration  testing  performed  prior  to  User  Operational  Testing  (OT) . 
Director,  AFVTF  will  ensure  that  software  expertise  is  available  during 
Government  DT  to  support  a  valid  technical  assessment  of  the  system. 

6.12  OPERATIONAL  TESTING  (OT) 

AFV  user  Operational  Testing  (OT)  will  be  conducted,  in  an  operational 
environment  as  determined  by  the  test  community.  OT  will  ensure  that  the 
system  will  satisfactorily  perform  the  mission  for  which  it  was  designed. 
Sufficient  OT  will  be  completed  before  Milestone  III  or  equivalent  to 
ensure  that  the  system  is  ready  for  proJ-action.  OT  will  be  managed  by  an 
independent  OT  agency,  with  support  from  the  material  and  combat 
developer.  aFVTF  will  ensure  that  the  software  e'T<'ti5B  is  available  as 
required  during  GT  to  support  the  evaluation  of  the  AFV  system. 

c.lG  ACCEf^''^Ah'C£  TESTING  -  Acceptance  testing  will  te  the  gateway  e'-ent. 
which  verifies  that  the  software  product  does  meet  performance,  aesign, 
and  quality  control  specifications.  Acceptance  Testing  will  include  the 
foil owi ng: 


Ensure  the  total  man-machine  interface  for  the  hardware/software 
package  is  acceptable. 

Ensure  proper  system  initiation,  data  entries  via  pt'ipheral 
devices,  program  loading,  restarting,  monitoring  and  control  of 
system  operation  from  display  consoles,  and  from  other  control 


stations  as  applicable. 
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a  Ensure  proper  inter-facing  of  all  equipment  specified  in  the 

program  performance  requirements. 

o  Ensure  the  capability  of  the  program  to  satisfy  all  applicable 

system  and  program  performance  requirements, 
o  Ensure  the  capability  of  the  system  to  handle  properly  and  survive 
erroneous  inputs. 

o  Perform  software  quality  stress  testing, 

o  Perform  review  of  documentation. 

o  Approval  for  Production.  Prior  to  a  full  production  commitment, 

AFV  PMO  will  ensure  that  the  operational  requirements  for  both 

performance  and  supportabi 1 i ty  have  been  met.  Approval  of 
computer  resources  for  production  will  require  that:  1)  the 

Functional  and  Allocated  Baselines  are  current,  2)  system-level 
FCA  and  PCA  are  completed,  3)  the  Product  Baseline  is  established, 
and  4)  all  three  baselines  are  under  proper  configuration 
management . 

A  description  of  the  contractor's  test  methodology,  as  aoproved  by  the 
Government,  will  be  inserted  after  contract  award. 

6.14  SL'^'PC^^TAPILl'I'y  DEMCNS'^PATIUN 

The  plan  for  the  conduct  of  the  supportati  1 1  ty  cemcnstrat  i  on  -^or  Life 
Cycle  Software  Engineering  Support  (LCSES)  will  be  defined  at  the  proper 
time  and  will  be  included  in  this  CRMP.  The  plan  will  delineate  and 
specify  the  requirements  ■‘or  the  testing  procedures,  internal  and  er.ternal 
interfaces,  equipment,  and  personnel  as  well  as  the  methodology  to  be  used 
to  verify  compliance  with  the  requirements.  The  demonstration  will 
exercise  the  support  capability,  in  real  time,  to  permit  assessment  and 
certification  of  its  adequacy  for  the  post  deplo/ment  phase. 


h.  20 
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6. 15  BENCHMARK.  TEST  CASES 


The  results  of  automated  computer  so-ftware  performance  evaluations 
accomplished  during  development  by  the  integration  contractor  will  be 
documented  and  maintained  by  the  AFV  LCSEC  during  post  deployment  support 
of  the  AFV. 

6.16  SOFTUIARE  DEFICIENCY  PROCEDURES 

The  contractor  will  be  required  to  prepare  a  software  deficiency  report  on 
any  software  requirement,  design,  or  test  deficiency.  Reporting  of 
deficiencies  will  be  done  in  accordance  with  the  Statement  of  Work  and 
CDRL.  The  contractor  will  be  responsible  for  resolving  all  software 
deficiencies  both  during  contractor  DT,  government  DT,  and  government  OT. 
All  deficiencies  will  be  identified  and  resolve  prior  to  Milestone  III. 

6.  17  TEST  SUPPORT  REQUIREMENTS 

6.17.1  Special  Tools 

Three  soecial  testing  tools  have  been  tenatively  identified  and  will  Pe 
used  in  the  testing  of  the  AFV  software  and  hardware.  Development  ana 
acduisition  of  special  test  tools  for  the  AFV  nas  not  vet  been  fwlly 
determined . 

6.17.1.1  Automation  and  Communications  Resources  Prototype  -  The  fFV 
system  integrator  will  construct  an  Automation  and  Communicatio  is 
Resources  Prototype  (or  mock-up)  containing  all  computer  related  hardware 
and  software  components  and  interfaces  or  emulators  of  those  components 
for  use  by  contractors  in  the  testing  of  software  modules/components.  The 
prototype  will  be  used  for  developmental  testing  at  the  systems  level  and 
for  support  of  DTStE  and  0T?<E.  At  the  completion  of  these  formal  tests, 
control  and  management  of  the  prototype  will  pass  to  the  AFV  LCSEC  for  use 

in  maintenance  of  the  AFV  computer  software  components. 
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6.17.1.2  Automated  Test  Suites  -  The  AFV  system  integrator  will  design 
and  produce  automated  test  suites  For  software  testing  at  the  system 
level.  The  test  suites  will  include  stress/overload  tests  and  system 
degradation  tests  in  addition  to  those  tests  needed  to  test  software 
component  according  to  specification. 

6.17.1.3  Software  Performance  Evaluator  -  The  system  integrator  will  also 
design  and  produce  automated  software  component  performance,  evaluation, 
and  diagnostics  programs  for  use  in  development,  testing,  and  maintenance 
of  AFV  computer  resources. 

6.17.2  Faci I i ties 

6.17.2.1  Developmental  Test  Evaluation  (DT?<E)  -  The  AFV  system 

integrator  will  provide  automation  and  communications  resources  testing  V 

facilities  for  AFV  contractors  and  for  military  participants. 

6.17.2.2  Operational  Test  Evaluation  (OT-VE)  -  The  AFVTF  will  arrange 
for  AFV  0T?<E  units  and  facilities  to  include  facilities  for  automation  and 
communications  resources  testing  by  the  integration  contractor  and 
selected  software  contractors. 

6.17.3  '^‘ersonnel 


6.17.3.1  DTS/.E  Personnel  Requirements  -  Technical  DT!(E  personnel 
requirements  will  be  determined  by  the  integration  contractor  and  approved 
by  the  AFV  PMO. 

6.17.3.2  OT.VE  Personnel  Requirements  -  User  OT.^E  personnel  requirements 
will  be  determined  by  the  AFVTF.  Contractor  representation  and  support 
during  OT!<E  will  be  coordinated  by  the  integration  contractor. 
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Test  Schedules 
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Figure  6-3 


6.25 

XV-VI-25 


UNCUSSSrit 


i  ; 


.V  V 


(THIS  PAGE  IS  INTENTIONALLY  LEFT  BLANK) 


AFV  CRMP  i  SEPTEMBER  1987 

3  ’ '  r’  '  V,  s^i c? i. n 

VOLUME  XV  U  ‘  plan  FOR  SUPPORT 

CHAPTER  7  -  PLAN  FOR  SUPPORT 

7. 1  INTRODUCTION 

The  Plan  -for  Supcort  Chapter,  presents  activities  which  must  take  place  in 
order  to  et-fectively  provide  Computer  Resources  support  Development 
Proveout  and  Production/Deployment  o-f  the  , AFV  system.  This  Chapter  also 
discusses  the  development  o-f  computer  resources  management  to  include  the 
AFV  Li-fe  Cycle  So-ftware  Engineering  Center  (s)  (LCSEC)  and  the  support 
philosophy,  the  support  organization,  and  responsibilities.  Support 

activities  necessary  throughout  the  life  cycle  phases  o-f  the  AFV  program 
are  defined.  The  support  -facilities  are  discussed  as  well  as  the  means 
which  will  be  used  to  maintain  AFV  system  integrity.  Configuration 

Management  planning  -for  the  post  deployment  portion  of  the  AFV  life  cycle 
IS  presented.  Personnel  and  training  requirements  are  identified. 

Testing  activity  for  post  deployment  AFV  is  discussed.  This  Chapter  of 
the  CRMP  defines  the  plan  that  will  be  established  and  followed  in 
providing  -t-or  the  life  cycle  support  of  the  AFV  automation  and 

communications  resources. 

euppcp-t  chiloscfhy 

riUDjo-^t  C'T  the  r-iFV  computer  resources  will  be  managed  C',-  the  AFVTF.  The 
i-UcuC  and  the  Automation  and  Communciations  Resources  Narking  Group 

(ACRWG)  will  assist  the  AFVTF  in  management  of  these  life  cycle  support 
aspects.  AFV  candidate  components  or  subsystems  (such  as  SINCGARS,  EPLRS, 
etc)  already 

7.1 
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under  a  P'^ogram  Manager  or  Program  Executive  Of-fice  will  retain  management 
r esponsi Qi 1 1 ty  and  will  update  their  respective  plans  to  support  the  AFV. 

7.  1.1.1  Plans  To  Establish  Support  Facilities  -  Plans  to  estaPlish 
support  tor  AFV  automation  and  communication  will  oe  -finaliced  prior  to 
Milestone  I/II.  It  is  anticipated  that  AFV  will  require  two  LOSEO's;  a 
vCOS  lOSEC  operated  by  TACCM  and  a  B2C2  LCSEO  operated  by  CECQM.  So-ftware 
engineering  support  -for  a  vehicle  defense,  position  navigation,  embedded 
training,  stand-alone  training  devices,  -fire  and  weapon  control,  automated 
logbook,  communication  control,  -fighting  station,  and  special  equipment 
control  must  be  -final  iced  by  a  work,  breakdown  structure.  Hardware 
(computer  and  communication)  engineering  support  will  be  developed  in  a 
similiar  manner. 

7.1.  1.2  Activities  Peouired  -for  L2SEC  Support  -  Tne  intense  activities 
necessary  to  prepare  an  uCSEC  facility  to  support  the  AFV  are  oresented  at 
^igure  7-1.  ’’hese  activities  are  described  at  Appenci;-  H.  It  is  planned 
that  during  Development  Proveout  (DFO) ,  at  least  two  uCSECs  will  be 
required  to  support  B^attaiion  and  Below  Command  and  Control  ;B2C2.' 
development  and  integration  and  to  support  the  AFV  Vehicle  Control  and 
Cperating  Svstem  '.VCCS'). 

'’.2  SU--'2=^  2'^GANI  ZA^IQN 


AFV  Li-fe  Cvcle  Support 


The  phases  throughout  the  AFV  System's  li-fe  cycle  which  will  require  LCSEC 
support  are  Development  Proveout  and  Production/Deployment.  The 
organization  and  relationship  o-f  the  LCSEC  to  the  AFVTF  during  these 
phases  is  shown  in  Figures  7-2  and  7-3. 

7.2.2  Support  Be-fore  Deployment 

The  Automation  and  Communications  Resources  manager  -for  the  AFVTF  is  the 
C3I  Division.  The  C3I  Division  is  responsible  -for  AFV  so-ftware  support 
during  all  phases.  Its  organization  is  shown  in  Figure  3-1  m  Chapter  3. 
The  AFV  software  m.aintenance  fnr  svstems  prior  to 
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Activities  Required 
■for 

Lite  Cycle  So-ftware  Engineering  Centers  (LCSEC) 
to  Support  the 

Armored  Family  o-f  Vehicles  (AFV) 


A.  Document  Mission  Critical  Computer  Resources  (MCCRs) 

B.  Identity  Personnel /Tecnni  cal  5t;ills  Needed 

C.  Create  a  Library 

D.  Acquire  Partial  So-ftware  Personnel  Crew 

£.  Identi-fy  Hardware  and  So-ftware  System  Components 

F.  Identi-fy  System  Support  Hardware  and  So-ftware 

G.  Acquire  Remaining  Personnel 

H.  Acquire  Documentation/Technical  Publications 

I.  Prepare  or  Update  So-ftware  Support  ^'lan 

J.  Familiarize  Personnel  with  System  So-ftware  Con-f  i  gurati  on 

K .  Prepare  LCSEC  Procedures 

L.  De-^ine  Space  and  Security  Requirements 

M.  Prepare  Test  Cell 

N.  Acquire  Ss'stem  and  Support  Items 
C,  S', 'Stem  Installation 

Develop  and  Conduct  Integration  P-ocedures 
C,  Develop  Con-f  i gurat i on  Management  (CM)  Plan  Annex 
K.  Conduct  system  Hardware  Training  o-f  Personnel 

S.  Conduct  software  Tests/Emul at i on 

T.  Center  Operations 

U.  Continuity  of  Operations  Planning 

V.  Administration  Preparation 


Figure  7-1 
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fielding  (Development  Proveout  and  Production/Deployment)  is  shown  in 
Figure  7-4.  This  system  will  evaluate  deficiencies,  failures  or 
additional  requirements  as  identified  by  the  User/Director  during  the 
developmental  phases  preceding  fielding.  As  the  figure  depicts,  the 
developer  (normally  the  prime  contractor)  is  responsible  for  correcting 
the  failure  or  addressing  the  requirement. 

7.2.3  Support  During  Testing 

If  the  testers  in  a  developmental/operational  test  (DT/OT,  II,  III) 
determine  a  failure  of  the  system  to  meet  requirements  or  specifications, 
they  may  generate  a  Test  Incident  Report  (TIR).  During  this  period  the 
Combat  Developer  (TRADOC)  may  consider  additional  requirements  for 
incorporation  during  a  Pre-Planned  Product  Imorovement  (P3I)  review  that 
will  be  held  following  the  system  Production  and  Development.  There  is  a 
very  relevant  point  as  concerns  cost  effectiveness  during  FSD 
(pre-production)  when  the  design  must  be  frozen  so  that  the  government  and 
the  contractor/developer  may  focus  on  the  product  to  be  produced.  This  is 
necessary  to  ensure  the  system’s  effectiveness  to  combat  a  new  or  changing 
threat  environment.  In  the  former  case,  the  generation  of  a  TIR  will  be 
processed  through  the  AFV  Director  of  Automation  and  Communication  *ar 
consideration;  and  in  the  latter,  the  requirement  will  be  staffed  througn 


;ho  AFVTF  offices. 


Should  these  offices  determine  that  the  need  la 


survivability  related,  it  becomes  an  AFV,  Chief  of  Communi cat: on  an: 
Automation  action.  Otherwise,  the  failure  report  will  be  processed  b'. 
another  one  of  the  paths  described  below. 
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7.2.4  Steps  in  So-ftware  Recon-f i ourati on 

The  -following  describes  the  steps  involved  in  AFV  So-ftware  Maintenance: 

A.  TRADOC  or  AMC  identi-fies  new  requirement  or  upgraded  capability. 
This  change  is  passed  on  the  Director,  AFVTF. 

B.  Test  ae-ficiency  or  design  de-ficiency  mani-fests  itsel-f  through 
Problem  Description  Report  (PDR) ,  Critical  Design  Review  (CDR) , 
or  Engineering  Change  Proposal  (ECP) .  De-ficiency  is  identi-fied 
to  Director,  AFVTF. 

C.  During  the  test  phase,  Test  Incident  Reports  (TIRs)  are  prepared 
by  the  test  activity.  TIRs  are  forwarded  to  the  AFVTF  Deputy 
Director,  Materiel  Development;  comments  and  recommended 
corrective  action  are  -forwarded  to  the  Director,  AFVTF  or  test 


sponsor  who  initiates  the  corrective  action. 


The  AFV  LCSEC 


establishes  the  receipt,  control,  and  assignment  of 
responsibility  for  corrective  action  on  TIRs.  (AR  70-13). 

AFVTF  coordinates  with  the  LCSEC  to  determine  e>:tent  and  impact 
of  all  TIP'S.  Director,  AFVTF  draws  selectively  upon  resources 
as  required. 

AFVTF  determines  necessity  and  method  of  implementing  change, 
e.G,,  P3I,  ECP,  change  to  e>;isting  cevelopment  contract.  Changes 


will  be  limited  to  those  considered  at-s  cl -.-.tel  v  essential 
and  e-^f active  system  per f ormar.ce. 
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F.  AFVTF  monitors  prime  contractor  to  assure  change  is  implemented. 
AFVTF  IS  supported  by  the  LCSEC,  and  other  agencies  during 
monitoring  efforts. 

7.2.5  Deployment  Support 

AFVTF  LCSEC  will  provide  technical  software  support  during  the  deployment 
phase  of  the  AFV  life  cycle  according  to  Figure  7-5. 

/ 

7.2.0  Post  Deployment  Support  -  The  developer's  Software  Development 
Station  (SDS)  and  simulation  facility  will  be  used  to  maintain  the  AFV 
Software  until  deployment.  Following  the  deployment  of  AFV,  the  LCSEC 
will  employ  a  multiuser  host  computer  to  support  software  changes  and 
modifications  for  the  AFV.  E::ample  of  the  steps  that  could  be  taken  by 
the  LCSEC  depicted  in  Figure  7-6  are  shown  below: 

A.  The  LCSEC  host  computer  will  central  ire  Configuration  Management 
and  keep  a  library  of  all  program  versions  including  source, 
object,  and  load  modules.  The  source  code  will  pe  loaded  into 
files  on  the  LCSEC  host  computer  using  magnetic  tape  or  othe- 
compatible  media. 

P.  Changes  to  the  source  code  will  be  made  using  cne  LCSEC  nost 

computer  program  development  environment. 

C.  New  versions  of  source  code  will  be  controlled  in  the  library. 

D.  Assemblers  will  translate  the  source  code  into  object  code. 
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The  object  code  is  in  the  •format  required  by  the  specific  target 
computer . 

A  link  program  will  resolve  the  entry  points  of  the  object 
modal es. 

The  link  process  creates  an  executable  load  module. 

The  load  module  may  be  debugged  on  the  LCSEC  host  computer  using 
developmental  software  tools.  This  is  only  sufficient  for  unit 
testing  since  timing  considerations  would  be  different  on  the 
LCSEC  host  computer  as  compared  to  the  actual  target  computers. 

The  load  module  may  also  be  downloaded  to  various  Microprocessor 
Development  Stations  (MDS) ,  as  needed. 

The  MDS  provides  real-time  debugging  capabilities  for  testing  of 
the  fully  integrated  systems. 


7.2.7  Software  Maintenance 

7he  system  for  maintenance  of  AFV  software  includes  repair  of  problems 
noted  during  development  or  following  deployment  of  the  AFV,  follow-on 
additions,  and  routine  updates  to  tne  system  software.  Regardless  of  tne 
source  the  software  changes,  all  changes  will  oe  processed  through  the 


7.3.1  Project  Management  Office  (PMO) 


The  to  be  designated  AFV  PMO  is  responsiole  for  establishment  and 
supervision  of  the  AFV  LCSECs.  During  Development  Proveout  the  LCSECs 
will  be  operated  by  the  system  integrator.  During 
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Production/Deployment  the  LCSECs  will  operate  under  the  AFVTF  with 
integrator  support. 


7.3.2  Lite  Cycle  So-ftwere  Engineering  Center  (LCSEC) 


The  AFVTF  with  support  -from  other  command  elements  will  ensure  that 
e-ftective  Lite  Cycle  Sottware  Engineering  Centers  are  established  and  the 
tollowing  actions  accomplished: 


Prepare  and  maintain  a  sottware  support  plan  responsive  to  AFV 


requirements. 


Determine,  acquire,  and  maintain  required  resources  tor  support 


ot  the  AFV. 


Pertorm  analysis  ot  sottware  and  support  sottware  changes  related 
to  problems,  system  changes,  requirements  changes,  doctrine 


changes,  etc. 

Develop  system  sottware  change  requirements. 


Develop,  design,  implement,  and  document  all  sottware 


moditications. 


tamtam  documentation  necessary  to  support  e::isting  ■‘lelded 


sottware  and  existing  support  sottware. 


Distribute  cnanges  m  accoroance  with  tne  -”7  Cont i gurati on 


Man aaement  Plan. 


lomplv  with  appropriate  cesion  stanca''ds,  prcgramming  starcaras, 


and  documentation  standards 
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Test  and  per-farm  evaluation  o-f  the  impact  o-f  changes  on  the 
operational  -function. 

Assist  in  user  acceptance  testing,  including  evaluation  o-f 
operational  suitability  and  operational  e-f-f ecti veness. 

Maintain  communications  and  procedures  between  the  -field  and  the 
support  Center  and  provide  guidance  to  the  -field  on  operation  and 
employment  o-f  the  AFV  as  related  to  so-ftware. 

Develop  system  test  and  analysis  so-f tware/hardware. 

Develop  and  maintain  simulators  and  emulators  where  required. 
Develop  and  conduct  training  necessary  to  introduce  a  new 

so-ftware  version. 

Develop  and  distribute  procedural,  operational,  training,  and 
maintenance  documentation,  and  special  operating  instructions. 
Prepare,  evaluate,  and  implement  ECPs  related  to  the  support 
so-ftware  or  hardware  required  when  changes  to  the  AFV  are 

approved. 

Provide  con-f  1  gurati  on  management  o-f  the  so-ftware  support  system. 
Coordinate  with  the  Materiel  Manager  and  TRADOC's  Combat 
Development  Support  Managers  to  estaolish  priorities  -for  so-ftware 
support , 
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Coordinate  with  the  AFV  ILS  Team  on  software  maintenance  support 
•functions. 

Participate  on  the  Con-figuration  Control  Board  (CCB)  ,  sub-boards 
■for  the  AFV,  and  working  groups. 

Other:  to  be  determined  (TBD) . 


7.3.3  Training  and  Doctrine  Command  (TRADQC) 

TRADOC  is  responsible  -for  keeping  the  AFV  LCSEC  in-formed  o-f  all  combat 
development  related  areas  which  might  impact  on  the  performance  of  AFV. 
Such  changes,  brought  about  by  new  doctrinal  employment  methocs, 
technological  advancements  in  target  surveillance  and  navigation 
techniques,  or  the  desire  to  utilize  different  configurations,  should  be 
coordinated  by  the  Directorate  with  the  AFV  LCSEC  for  further  analysis, 
evaluation,  and  implementation  if  directed  by  the  AFV  PMO.  Additionally, 
the  Directorate  is  responsible  for  providing  definitions  and  guidance  for 
establishment  of  standard  scenarios  required  in  support  of  testing. 

7.3.4  Army  Materiel  Command  'AMO 

AMC  15  resDcnsible  for  keeping  the  LCSEC  inforneo  of  all  acuisition 
related  areas  which  may  impact  on  future  development  -of  automation  arg 
communi cati ons  resources  for  the  AFV. 

7.3.5  Prooram  E>;ecutive  Officer  (PEO) 


7.4  DOCUMENTATION  SUPPORT 

Documentation  support  for  the  AFV  software  must  be  maintained  at  the 

system  and  susbsystem  levels.  Automatic  documentation  support  must  be 

made  available  to  AFV  system  developers. 
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7.4.1  System  Documentation 

System  documentation  necessary  to  support  AFV  will  include  all 

documentation  called  -for  by  DQD-STD-2167: 

A.  Software  Requirements  Specification 

B.  Software  Product  Specif ication 

C.  Software  Top  Level  Design  Document 

D.  Software  Detailed  Design  Document 

E.  Software  Test  Plan 

F.  Software  Test  Procedures 

G.  Software  Test  Reports 

H.  Software  Quality  Assurance  Plan 

I.  Software  Development  Plan 

J.  Summary  Reports  from  hardware  and  software  Critical  Design 
Revi ews 

f.  Software  test  plans  and  procedures  used  for  unit  and/or 

integration  testing  on  AFV  software  during  development. 

L.  Results  and  procedures  from  Software  tests. 

M.  Interface  Control  Documents  (ICD) 

N.  System  Operator's  Manual 

O.  All  otner  records/reports  from  CM  prcoedves  S'-cn  as  'Cut  not 
limited  to)  reports  *rom  Functional  and  '^■'oduct  Con*  i  gu’^ati  o' 
Audits,  Formal  Dual  i  f  i  cati  on  Review,  Conf  i  tL'rati  on  Item  -e-.  iew. 
any  documents  from  Conf i gurati on  Status  Accounting,  Baseline 
Management,  of  Software  Change  Status  Reports. 

P.  Other:  TBD 

7.4.2  Subsystem  Documentation 

All  Subsystems  require  the  fallowing  documentation: 
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A.  Listing  of  compiled  software  software  including  source  language 
statements  and  comments  with  resulting  object  machine 
instructions. 

B.  Flowcharts,  HIPO's,  and/or  any  other  logic  diagrams  and  graphic 
representation  (Both  Type  level  and  detailed  design  documents). 

C.  Descriptive  abstracts  at  the  beginning  of  the  executable  code 
including  inputs,  outputs,  and  function  or  task,  list  of  other 
components  called. 

D.  Cross-reference  listings. 

E.  Load  maps  describing  the  format,  method,  and  location  where  the 
various  components  are  loaded  in  the  system's  computer. 

F.  User/Maintenance  Manuals. 

G.  All  documentation  on  all  Simulators  used  for  the  AFV. 

H.  Other:  TBD 

7.5  COMPOSITE  SYSTEM  INTEGRITY 

The  AFV  LCSEC  will  be  responsible  for  the  integrity  of  the  AFV  computer 
resources  and  will  maintain  positive  control  of  the  following  as  a 
mini  mum . 

A.  Computer  Storage  Utiliration. 

B.  Computer  Program  Operating  Time  and  Priorities. 

C.  Computer  Program  Interface  Techniques. 

D.  Computer  Baseline  Integrity. 

E.  Utilization  of  Computer  Modules  and  Peripherals. 
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7.6  CONFIGURATION  MANAGEMENT 


Con-f  iguration  Management  is  the  application  o-f  technical  and 
administrative  direction  and  surveillance  to  the  identification  and 
documentation  o-f  -functional  and  physical  characteristics,  the  control  of 
changes  to  those  characteri sti cs,  and  the  recording  and  reporting  of 
change  processing  and  implementation  status.  The  primary  configuration 
manaqement  functional  areas  include: 


Configuration  Identification 
Configuration  Control 
Configuration  Status  Accounting 
Configuration  Audits  and  Reviews 
Document  Control 
Other:  TBD 


These  procedures,  when  carefully  applied,  will  provide  assurances  that  the 
AFV  computer  resources  will  attain  their  required  performance,  schedule, 
operational  efficiency,  logistic  support,  and  readiness  goals. 

7.6.1  Conf 1 gurati on  Identification 


Configuration  identification  is  establ  i  sned  c.  tne  ourrenclv  aoo-'o.ed 
technical  documentati on  of  conf iguration  iters  'CIi.  conf i our  at i on 
identification  documents  include  all  those  necessary  to  provioe  a  full 
technical  description  of  the  Cl  characteristics  that  require  control  in 
the  AFV  system.  This  includes  specifications,  drawings,  listings,  charts, 
and  other  approved  design  documents. 


7.6.2  Conf i qurati on  Control 

The  configuration  of  AFV  software  is  controlled  by:  Establishing  its 
baseline  (configuration  identification);  controlling  all  changes  from  that 
baseline  through  evaluation,  classification,  quality  control,  test,  ano 

■ 
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validation;  and  assuring  that  the  hardware  and  software  match  the  current 
configuration  identification  including  approved  waivers  and  deviations.  A 
software  change  or  modification  is  classified  as  an  error  correction, 
system  refinement,  new  requirement,  or  interoperability  interface. 

A.  Error  Correction  is  performed  on  latent  defects  (problems  not 

discovered  during  development)  and  functional  defects  (problems 
discovered  during  operational  use). 

B.  System  refinement  usually  deals  with  optimizing  programs, 

improving  system  performance,  and  incorporating  technological 
advances.  Included  in  this  category,  are  evolutionary 

modifications  to  applications  software  in  response  to  evolving  or 
changing  tactical  doctrine  and  threat. 

C.  New  requirements  are  program  modifications  which  result  from 

major  changes  or  new  application.  Changes  categorized  as  new 
requirements  are  to  be  managed  as  Product  Improvement  Programs 
(PIPs)  in  accoroance  with  AR  70-15. 

D.  Interoperability  interface  configuration  changes  or  modifications 

are  those  affecting  -ne  csign  baseline  of  those  systems 

controlled  by  Battlefiexd  Interface  Imol ementati on  Plans, 

Interoperati 1 ity  Design  St- 'dards,  or  Technical  Interface  Design 
F'  1  an  s . 
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7.6.3  Corrf iquration  Status  Accounting 

The  status  accounting  -function  provides  -for  the  recording  and  reporting  o-f 
the  in-formation  that  is  needed  to  make  configuration  i  dent  i-fi  cat  ion 
control  -for  AFV  workable.  The  technical  documentation  that  will  be 

recorded  includes: 

A.  The  con-figuration  i denti -f ication  (baseline) 

B.  Approved  changes  to  the  con-f i gurati on  and  the  implementation 

status  o-f  such  changes 

C.  Contractual  in-formation  required  -for  each  Cl  and  contractor 
identi-f  ication 

D.  Proposed  changes  to  the  con-f  i  gurati  on  and  the  status  o-f  such 

changes. 

Con-f  iquration  Audits  and  Reviews 

Con-f  i  gurati  on  audits  and  reviews  are  per-formed  to  veri-fy  that  a  completed 
Con-f  i  gurati  on  Item  (Cl)  con-forms  to  :=  soeci-f  ications,  drawings,  and 
other  contractual  requirements.  The  -ilowng  ccn-f  i  gurati  on  audits  and 
reviews  are  reouired: 

-uncticnal  Con-^  1  curat  1  Oh  ^,dit  -  The  ^CA  -.  s  ci^ducced  cc 

O'hcleted  Cl  will  oer-farm  as  intended. 

7. 6.  4. 2  ^'hysical  Con-f  10 1,1."  at  ion  Aunit  (P’CA)  -  The  PCA  is  conducted  to 
veri-fy  the  contractor's  proposed  baseline  accurately  a-d  completely 
describes  the  as  built  Cl. 

7.6. 4.3  Formal  Dual  i -f  i cat i on  Review  (P'QF)  -  The  FDR  is  conducted  to 
identi-fy  test  reports  and  test  data,  to  veri-fy  test  reports  and  test  data, 
and  to  establish  that  the  demonstrated  per-formance  o-f  a  Cl  (as  documented 
by  these  tests)  is  in  compliance  with  the  Cl's  Development  Specification. 
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7. 6. 4. 4  Con-figuration  Item  Verification  Review  (CIVR) 


The  CIVR  IS 


conducted  to  verify  that  the  system  has  been  produced  and  tested  in 
accordance  with  the  current  Product  Configuration  Identification  <PCI). 

7.6.5  Configuration  Control  Board 

The  Configuration  Control  Board  and  the  Automation  and  Communications 
Resources  Working  Group  AFV  are  the  primary.  AFVTF  configuration  management 
organisations.  Their  responsibilities  are  outlined  below, 

7.6.5. 1  Configuration  Control  Board  (CCB)  -  The  CCB  is  the  primary  medium 

for  managing  hardware  and  software  change  control  and  release.  For  the 
purpose  of  controlling  and  validating  software  changes/modifications,  the 
CCB  IS  responsible  for  determining  the  validity  of  all  proposed 
changes/modifications  to  the  AFV,  approving/disapproving  these  proposals, 
and  classifying  any  that  are  approved.  The  CCB  thus  maintains  the 

integrity  of  the  baseline.  CCB  implementation  will  occur  prior  to 
Milestone  III.  Membership  is  in  the  CCB  includes  as  a  minimum: 

A.  Selected  AFVTF  Representatives 

B.  AFVTF  LCSEC  Representative 

C.  AMC  Representatives 

D.  TRADOC  Representatives 

E.  Other  Functional  areas  as  required 

7. 6. 5. 2  Automation  and  Communications  Resource  Working  Group  tACRWG)  - 
With  respect  to  CM,  the  ACRWG  ensures  that  the  computer  resource  planning 
is  reflected  in  the  CRMP  adequately  addresses  CM  requirements  determined 
by  the  AFVTF. 
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7 . 8  TRAINING  REQUIREMENTS 


7.8.1  AFV  LCSEC  Traininc 


As  required,  AFV  LCSEC  personnel  will  receive  hardware  and  so-ftware 
training  as'i  soon  as  possible  according  to  the  activities  required  for 
LCSEC  to  support  the  AFV.  On  the  Job  Training  (OJT)  is  the  least 
preferred  method  of  training  provided  acceptable  formal  training 
facilities  e::ist,  Personnel  requiring  extensive  software  training  require 
AFV  C3I  Division  Chief  approval. 

7.8.2  User  Training 

At  this  time  user  training  will  be  incorporated  in  the  AFV  Individual 
Collective  Plan,  published  separately. 

7.9  TESTING 

Testing  support  is  covered  in  Chaoter  6, 

7.9.1  Tgstmc  ^'olicv 

Cevel oomental  and  Formal  testing  oolicy  will  be  se'.-lcbeC,  'etireo,  ?"b 
used  for  testing  of  software  corrections  and  maintenance. 

7.9.2  Independent  Verification  and  Validation  (IV^V) 

Independent  Verification  and  Validation  will  be  accomplished  by  the  system 
integrator. 

7.10  TRANSFER  OF  PROGRAM  MANAGEMENT  RE5P0NSIBIL ITV 

Due  to  the  continuing  developmental  nature  of  the  AFV  system,  it  is 
expected  that  the  AFVTF  will  evolve  into  a  Program  Executive  Office  (P£0) 
and  continue  as  the  overall  developer/manager. 
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7. 11  SYSTEM  MODIFICATIONS 

AFVTF  LCSEC  will  provide  system  modi -fi cation  and  enhancement  support 
throughout  all  phases  of  the  AFV  life  cycle. 

7.11.1  Introduction  of  Modifications 

Once  a  modification  has  been  approved,  users  will  be  provided  with  the 
required  changes.  To  accomplish  this  function,  four  processes  must  occur: 

o  The  Replication  Process 

o  The  Shipment  Process 

Q  The  Installation  Process 

o  The  Collection  Process 


7.11.2  The  Reel  1  cation  Process 


Upon  completion  of  verification,  validation,  and  testing  of  all 
changes,  the  software  or  hardware  will  be  produced  in  the  required  amounts 
for  distribution  and  installation  in  the  AFV.  Special  documentation,  :f 
needed,  will  be  produced  for  pac>  . ging  witn  tne  reolacement  so*twarp 
component . 


7.11.3  The  Shipment  Process 

Distribution  to  the  field  will  be  accomplisned  ;n  onit  sets  lAW 
approved  AFV  fielding  strategy.  Cn tical /Emergency  distributions  of 
master  change  packages  will  be  made  to  AFV  PMO  LCSEC  field  support  teams 
for  local  reproduction  and  installation. 
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7.11.4  The  Installation  Process 

Installation  o-f  routine  so-ftware  changes  in  individual  AFV's  will  be 
accomplished  at  the  unit  maintenance  level  either  by  installation  of  a 
repl acement/add-on  hardware  component  or  by  use  an  externally  connected 
software  update  capability. 

7.11.5  The  Collection  Process 

An  automated  record  o-f  the  so-ftware  versions  -for  each  AFV  will  be 
collected  and  -forwarded  to  the  AFVTF  LCSEC  -for  the  purpose,  of 
con-f  igurati  on  management. 

7. 12  LIFE  CYCLE  COSTS 

Automation  and  communciation  resources  will  be  costed  in  the  -following 
areas.;  development,  production,  fielding,  and  materiel  and  personnel 
sustainment.  Cost  data  must  differentiate  between  AFV  required  and  AFV 
support.  AFV  reouired  costs  are  those  costs  directly  required  for  AFV. 
AFV  suDPort  costs  are  based  on  these  svstems  which  would  be  fielded  by  the 
^'■my  wifo'.t  -FV  i.s.  SIfJGCAF'S,  MSE,  AFATDS,  etc). 
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7.12.4  Materiel  Sustainment  Costs 


7.12.5  Personnel  Costs 


7.13  FUNDING 

AFVTF  will  establish  ■funding  priorities  base  on  AMC  and  TRADOC 
recommendations.  AMC  and  the  Department  O'f  the  Army  have  -funding 

responsibility.  AMC  will  be  responsible  fo  obtaining  technology  base  -for 
AFV  research  and  development,  operational  maintenance  (Army,  DMA)  Por 
engineering  and  installation  and  procurement.  Department  o-f  the  Army  will 
accomplish  -funding  actions  required  -for  -fielding  support. 

’.14  ’echncldgv  Assessment 

’he  purpcse  o-f  the  AFV  Technologv  -issessn-ie^.t  is  tnree-* ;  1  : .  -i-^st.  it  is 

designed  to  identify  technology  base  ib.l-6.3Ai  ano  proauct  manaqeo 
projects  applicable  to  AFV  -fielding  and  F3I.  Seccnc,  it  is  designed  to 
identify  dollars  and  resources  required  to  field  these  projects  or  insert 
the  technology  into  the  AFV.  The  Mission  Area  Materiel  Flan  (MAMP) ,  Long 
Range  Research  Development  Activities  Plan  (LRRDAP)  and  Program  Objective 
Memorandum  (POM)  are  to  be  effected  and  tailored  to  AFV.  TRADOC  and  AMC 
have  primary  responsibility  to  ensure  Army  dollar  resource  plans  reflect 
AFV  objectives. 
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The  third  purpose  o-f  the  technology  assessment  is  to  identi-fy  projects 
which  are  not  applicable  to  AFV.  The  Technology  Assessment  in  Volume  IX 
-for  the  Task  Force  products  will  be  continually  maintained  during  the  AFV 
life  cycle.  AMO  has  primary  responsibility  for  maintaining  the  AFV 
Technology  Assessment. 

7.  15  SUMMARY.  FLAN  FOR  SU^^'g'QFT 

Chapter  7  is  the  support  plan  for  AFV  automation  and  communications 
resources  support  throughout  the  life  cycle  of  the  AFV. 
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ACCS 

ACCSS 

ACRWG 

ADA 

Ada 

ADEA 

AFV 

hFVTF 

AMC 

AMCCDM 

AMSAA 
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ACRONYMS  AND  ABBREVIATIONS 


Army  Command  and  Control  System 

Army  Command  and  Control  Subordinate  Systems 

Automation  and  Communications  Resource  Working  Group 

Air  Defense  Artillery 

DOD  Standard  Programming  Language 

Development  and  Evaluation  Agency 

Armored  Family  of  Venicles 

AFV  Task  Force 

Army  Material  Command 

Armament,  Munitions,  and  Chemical  Command 
Army  Materiel  Systems  Analysis  Activity 


ARDEC 

Armament  Research  and  Development  Engineering 

Center 

ARI 

Army  Researcn  Institute 

ARO 

Army  Research  Office 

A3AS 

All  Source  Analysis  System 

AVSCOM 

Armv  Aviation  Systems  Command 

AV3RDA 

Aviation  Systems  Research  and  Development  Acti 

VI  ty 

E2C2 

Battalion  Below  Command  and  Control  Svstem 

BIT 

Built  In  Test  • 

BITE 

BIT  Equipment 

BMS 

Battlefield  Management  Svstem 

BRDEC 

Bel  voir  Researcn  and  Development  Engineering  Center 

BRL 

Ballistic  Research  Laboratory 

C2 

Command  and  Control 

C3I 

C2,  Communications,  Intelligence 

CAC 

Combined  Arms  Center 

CACDA 

Combined  Arms  Comoat  Development  Activity 

CCB 

Configuration  Control  Board 

CCS 

C2  Systsms 

CD 

Comoat  Develooer 

CDP 

Critical  Design  Review 

CDRL 

Contract  Data  Pequirementa  List 

CECOM 

Communications  and  Electronics  Commano 

CEO  I 

Communications  Electronics  C-Derating  Inst'^ucti 

ons 

CF 

Conf iguration  Management 

Cl 

Configuration  Items 

CIVR 

Configuration  Item  Verification 

COMSEC 

Communications  Security 

CPDP 

Computer  Program  Development  Plan 

CRDEC 

Chemical  Research  and  Development  engineering 

Center 

CRISD 

Computer  Resources  Integrated  Software  Support 

Document 

CRMF 

Computer  Resource  Management  Plan 

CSC 

Computer  Software  Component 

CSC  I 

Computer  Software  Configuration  Item 

CSS 

Combat  Service  Support 

CSSCS 

Combat  Service  Support  Control  System 
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DBDD 

DE 

DEM 

D/P 

DOD 

DT 
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DT)kOT 

ECP 

EPLRS 

ETAS 

ETDL 

ETL 

FAAC2I 


FCA 

FIST 

FGR 

FRAGO 

FS 

FSD 

FEED 

FV 

GFE 

GOSC 

MCI 

MDL 

HEL 

HFE 

HFTE 

HCL 

H3C 

ICB 
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ILS 
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INSCOM 

IQT 
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JMSNS 

JTIDS 
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Department  o-f  the  Army 
Data  Base  Design  Document 
Directed  Energy 
Directed  Energy  Weapon 
Development  Prove  Out  Phase 
Department  o-f  De-fense 
Demonstration  Test 
Demonstration  Test  and  Evaluation 
Developmental  Test/Qperational  Test 
Engineering  Change  Proposal 
Enhanced  PLRS 

Elevated  Target  Acquisition  System 
Electronic  Technology  and  Devices  Laboratory 
Engineering  Topographic  Laboratories 

Forward  Area  Air  De-fense  Command,  Control  Intelligence 
System 

Functional  Configuration  Audit 

Fire  Support  Team 

Formal  Qualification  Review 

Fragmentary  Oraer 

Fire  Support 

Full  Scale  Development 

Full  Scale  Engineering  Develooment 

Fighting  Vehicle 

Government  Furnished  Equipment 

General  Officer  Steering  Committee 

Hardware  Configuration  Item 

Harry  Diamond  Laboratory 

Human  Engineering  Laboratory 

Human  Factors  Engineering 

Human  Factors  and  Training  Board 

High  Order  Language 

Health  Services  Command 

Interface  Control  Board 

Intelligence  Electronic  Warfare 

Integrated  Logistics  Support 

Integrated  Logistics  Support  Plan 

Intelligence  and  Security  Command 

Initial  Operational  Test 

Independent  Verification  and  Validation 

Justification  for  Major  System  New  Start 

Joint  Tactical  Information  Distribution  Svstem 
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LABCOM 

LCSEC 

LOSS 

loocen 
lOS  ad 

LCS  AT 
LRU 
MANPR 
MAPS 
MCCR 
MCS 
MD 
MD3 
MEP 


NT 


Laboratory  Command 

Li-fe  Cycle  So-fti^are  Engineer  Suooort 
Paci 1 1 ty 

Li-^e  Cycle  Sc-ftware  Eupocrt 

Lcgi sties  Center 

Line  ot  Sicrt,  Air  De-fense 

Line  at  Signt,  Anti-Tant 

Line  Replaceaole  Unit 

Manpower  and  Pereonnel  Integration 

Mobile  Arimatn  Positioning  Svstems 

Mission  Critical  Computer  Resources 

Maneuver  Control  System 

Materiel  Developer 

Microprocessor  Development  Stations 

Mission  Eouipment  Package 


-enter , 


MI  COM 

Missile  Commanc 

N-C  T-  /  »■  r  t  T  7  T 

>w  a  / 

HCI  DA  01  rest 

50  Mil est 

ones 

MSE 

Mobile  Eubsc 

riben  Eou 

1 pmert 

M3C 

Ma.’or  Sun  ore 

mate  CommanO 

NATO 

Nortb  At  1  ant 

10  Treaty 

Organic  at: on 

NBC 

Nuclear,  Bic 

logical , 

Chemical 

NLCS 

Non  Line  o-f 

Sigbt 

OPSEZ 

Goeraticnal 

Secur 1 ty 

OT 

Cpe-'at  1  onal 

'■  05  t 

Cipe'^ati  anal 

Test  anO 

Evaluation  Agency 

C'peratianal 

'est  and 

E  val  ■-  ati  cn 

“  •? ,  “■ 

uoerational 

and  Or  can 

icatian  Plan; 

-reo; anr 


Improvement 


-  C-' 

-n  /  SI  cal 

Con*  id'.'.rati  on  Audit 

“  -  * 

-  •“  C'  C  v'  c  t. 

Cent  1  curat  1  cr,  Ice'" t;  -  i  c  at ; 

Pr-Dgrafn 

Design  Lanouaoe 

=  DR 

-•"el  2  .Til  rar  y  Design  Review 

R rob  1 em 

Desoription  Report 

PE 

Project 

Enci neer 

PEG 

Program 

E;;ecutive  0-f-ficer 

PIP 

Product 

Improvement  P'^ogram 

PLR3 

Posi 1 1  on 

Location  Recording  System 

C'M 

Prognsm 

Manager 

PMCS 

Program 

Management  Control  System 

PMD 

Program 

Management  Documents 

C-MQ 

P  ■'ogram 

Management  Office 

Project 

Manaement  Office 

POC 

Point  oP 

Contact 

cnc- 

Proc-f  o-f 

Principle 

Activity  or 
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CDR 

ROC 

R3TA 

SAPPER 

SAVA 

SCI 

SDDD 

SDP 

SDR 

SDS 

SETA 

SIGCEN 

SINGCARS 

SITREP 

SOW 

SPS 

SQA 

SRR 

SRS 

SSC 

SSR 

STAMMIS 

STD 

STLDD 

3TP 

SIR 

TACOM 

TECGM 

■^EMP 

'I'E'IPEST 

TMDE 

T.VE 

TIR 

TIWG 

TCATA 

i  TRAC 

TRADOC 
TROSCOM 
USA I  SC 
'  USALEA 

VCOS 

‘  VDD 

;  VETRONICS 

.  VIDS 

;  wBS 

r 

> 

I 


Quality  De-ficiency  Report 

Required  Operational  Capabilities 

Reconnaissance  Surveillance  Target  acquisition 

APV  Engineer  Vehicle 

Standard  Army  VETRONICS  Architecture 

So-ftware  Con-f i gurati on  Item 

Software  Detailed  Design  Document 

SoPtware  Development  Plan 

System  Design  Review 

So-ftware  Development  Station 

Systems  Enginnering  and  Technical  Assistance 

Signal  Center  School 

Single  Channel  Ground  Airborne  Radio 

Situation  Report 

Statement  o-f  Work 

So-ftware  Product  Speci-fi cation 

So-ftware  Quality  Assurance 

System  Requirements  Review 

So-ftware  Requirement  Speci-fi cation 

Soldier  Support  Center 

So-ftware  Soeci-f ication  Review 

Standard  Army  Multicommand  Management  In-formaticn  Systems 

So-ftware  Test  Description 

So-ftware  Too  Level  Design  Document 

So-ftware  Test  Plan 

So-ftware  Test  Reports 

Tank  and  Automotive  Command 

Test  and  E-.'aluation  Command 

Test  and  Evaluation  Master  Plan 

Telecommunications  Electronic  '^ateriel  -'cteotea  ^'o-n 

Emanating  Spurious  Transmi ss: ons 

Test  Maintenance  Diagnostic  Eouipment 

Test  and  Evaluation 

Test  Incident  Report 

Test  and  Integration  Working  Group 

TRADOC  Combined  Arms  Test  Activity 

TRADOC  Analysis  Command 

Training  and  Doctrine  Command 

Troop  Support  Command 

U.S.  Army  Information  Systems  Command 

U.S.  Army  Logistics  Evaluation  Agency 

Vehicle  Control  and  Operating  System 

Version  Description  Documents 

Vehicle  Electronics 

Vehicle  Integrated  Defense  System 

Work  Breakdown  Structure 
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VEHICLE  SYSTEM  SUMMARY 


VAR  I  ANT  NOMENCLATURE 


MISSION 


EXISTING  VEHICLE* 


ASSAULT  FV-1  ATTACK  VEHICLE  TANK 

FV-2  ASSAULT  VEHICLE  INFANTRY,  SAPPER- 

AMBULANCE,  FI3TV, 
COMMAND  GROUP, 
RECQN,  DEW 

FV-3  ASSAULT  FIRE  LOS-AD 

VEHICLE  L03-AT 


M60A1-A.3,  Ml,  MlAl,  M48A5 

BFv  W/TOW  OR  AAWS-H:  MllCAl-AI 
M9B1  FISTV,  ambulance 


KEM  ON  CHASSIS;  M741  W/Mle3 
VULCAN;  LOS  FH  ON  M-2/MLRS  OR 
MllC;  DUSTER  M42A1;  M901 


FV-11  ASSAULT  MOBILITY  COMBAT  MOBILITY/ 
VEHICLE  OBSTACLE  BREACH 


COV;  M72a  CEV;  BULL  DOZER; 
TANK  W/ROLLER/PLDW 


FV-10  ASSAULT  BRIDGE  GAP  CROSSING 


ASSAULT  FV-4  ASSAULT  FIRE  ANTIARMOR/ANTIAIR 
SUPPORT  SUPPORT-MISSILE 


FAAD  (NLCS)  ON  MLRS  CHASSIS: 
LRAT  ON  MLRS  CHASSI'S. 


FV-5  ASSAULT  FIRE 
SUPPORT  GUN 


HOWITZER 


AFAS;  HIP:  M10^A2-A3. 


FV-7  ASSAULT  SUPPORT  NBC  RECON, 
VEHICLE  rearm, 

REFUEL , 

RESUPPLY , 
MAINTENANCE, 
3MOK.E  GENERATIOr- 
MORTAR , 

ambulance . 

MINE  DISFENSr.-’ 


M992  FAASV:  M54a:  M501A3 
TPU;  M'l'^'ADC;  -EMTT  £R 

M545,  M35A;C:  5  ^0^.  hEm'T 
Ml  13:  MC7S:  '"Ml  35 


-V-a  ASSAULT  SUPPORT  BATTLEFIELD  REPAIR  ■>  M33A1-A2:  MCS 
VEHICLE  RECOVERY  EVACUATION 

BATTLE  FV-6  BATTLE  FIRE  DEEP  BATTLE  SUPPORT  MLRS  M270 

SUPPORT  VEHICLE  MULTIPLE  LAUNCH  ROCKET 


FV-9  C-*  VEHICLE 


C=;  ETAS;  lEW 


AN/MLO-34  TACJA'-";  AN/M50-1:;3C 
TEAM  PACf  :  AN/TSC'-l  :“B  ^“Aic- 
BLAZER;  MC^Al-AC;  ''113;  A'-., 


♦  APV  wi 1 1  replace 
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ARMORED  FAMILY  OF  VEHICLES  (AFV)  AUTOMATION  AND 


IQMMUNICATIQN  RESOURCES  WORKING  GROUP 


(ACRWG) 


CHARTER 


ARMORED  family  OF  VEHICLES  TASK  ^QRCE 


DAMO-AFV-M 


FORT  EUSTIS,  VIRGINIA  23602-5597 


AUTCVQN  927-1465/&C 


;OMM  (S04i  £■’’5- 14c 


Append:::  C 

o-f  the  AFV  Computer  Resource  Management  Plan  (CRMP) 
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1 .  PURPOSE 


To  formally  esoaLlisn  tne  AFV  Automation  and  Communications  Resources 
HorVanq  broup,  hereafter  referred  to  as  the  ACRWG.  The  orimary  puroose  of 
the  hCPWG  is  to  provide  a  forum  for  direot  communication  in  accomp  1 1  shi  r,c 
the  oPjectives  and 

r esDOhsi di 1 1 t 1 es  outlined  in  oaragraohs  4  and  C.  This  charter  will  oe 
'"e'.'iewed  annual  Iv  on  its  anniversary  date  nor  necessar,  re/isions. 


PE-ER.EffCE  DDCUMENTS 


a.  Resource  Manaoement  uocuments: 


(1)  CCD  Directive  5000.  C'P,  '•Management  o-  Comouter  Resources  in 
Major  Defense  Evstems,  2b  Apr  7a. 

(2i  AF'  100''1'-1,  E'asic  ^‘olicies  for  System  Accui  si  ti  on .  1  May  E3 
(3)  AR  70-1,  System  Acquisition  Policy  and  Procedures.  12  Nov  56. 
m4)  AR  71-9,  Mate-1  el  Objectives  and  Requi-ements .  a  05. 


fPV  Dccuirents: 


A  compiete  listioq  c- 


Ihe  -nV  Or  oC-aiT. . 


The  AFV  ACRWG  membership  includes  representatives  of  the  corriCat  developer, 
material  developer,  development  and  operational  teste-s  and  evaluato-s, 
and  the  designated  post-deployment  support  activity.  A  -Cull  listing  o-f 
the  member  organi cations  is  presented  in  Figure  C-1.  A  roster  of  the 
Cesignated  individual  mem'bens  is  provided  in  Annex  1.  of  this  docL^ment. 
along  with  their  mailing  address  and  telephone  number. 
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|CRWG  Membership  I 


I  DIRECTOR  j 
I  AFVTF  j 

I _ 1 


I  CHAIR  1 

I  DEPUTY  DIRECTOR,  MATERIEL  ] 


I  I 

I  SITTING  CHAIR  | 


1  MEMBERSHIP  | 


T 


1 - - 1 

,  'ECHNOLCEY  j 

1  1 - - - 1  1  I - i  1 

j  1  CRMP  1 1 [LCSEC  1  1 

1 

[  1  HUMAN 

1  INTEGRATION/  1 

1  1  PLANNING| 1 [PLANNING  |  j 

1  1  FACTOR'D 

; ASSESSMENT  ; 

1  1  GROUP  ; j  j  GROUP  j 

1  )  and 

j  GROUP  1 

1  > 

1  1  II  1 

1  1 - 1  1 

1  j  TRAINING 

1  ' - 

I  SPECIFICATION  | 
I  DEVELOPMENT  j 
I  GROUP  ( 

I  -  1 


SUBSYSTEM) 
COMPONENT  I 
GROUP  I 


I  ACRWG  I 
[MANAGEMENT) 
I  GROUP  I 

I _ I 


Figure  C-1 
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Changes  :n  membership  sr.aii  be  made  by  the  participating  organi  cat  i  ons  in 
a  formal  notiTication  to  the  ACRWG  chair.  The  chairmanship  the  ACRWG 
15  vested  in  tne  Cep^itv  Cirectbr,  Materiel  Development  who  is  designated 
as  the  Aatomatior  and  Cammon  i  c  at  i  on  Resource  Manager  tor  A^^V  managed 
s/stems  anc,  as  sict,  ^eccrts  directly  to  the  Director,  Armored  ^amilv  ct 
le^ic.es  asr  “crce. 


■'“Spur  ce 


■d'.ices  a  ♦c'.m  ’dr  t..0  "eview  and  resoliition  o-f  comouter 
.es  that  .T.av  imcact  tne  ac  Qd  i  s  1 1 1  on  .  depldvme''t.  and  support 


"e  speci'ic  cc:e:ti-es  o-’  the  "._nwo  are: 


man.  a  deme'"  t 


■a  Mr.-  *:eet.  Support 


a-tomat 1  on  and 


♦f  f'e  A- V  ♦rr.m  s-ibs.'Stem  through  'amiiy 


ESG-ur  ces. 


'c  pro, mote  the  use  o*  aoproved  HQL ,  comp  ilers,  a"'C  other  sottware 
tools  in  the  system. 

To  assist  the  Director,  AFVTF  in  initiating  early  tasf s  and 
activities  that  are  prerequisites  to  the  development  and  test 
functions  o-f  the  Af^V. 
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To  assist  the  Director  in  ensuring  compliance  with  DA  policy, 
procedures,  plans,  and  standards  established  -for  the  acquisition 
of  computer  resources. 

To  facilitate  preparation,  review,  and  approval  of  the  system's 
CRMP. 

To  eliminate  unnecessary  redundancy  in  testing. 

To  ensure  that  the  integration  of  AFV  Management  Plans. 

To  facilitate  trainer/materiel  developer  coordination  in  the 
development  cf  appropriate  training  programs  Ce.g.,  ^^ew 
Equipment  Training  (NET),  Individual  Collective  Training 
Plans  ( ICTP) . 

To  assure  the  timely  turnover  of  the  system  to  the  using 
command  and  an  orderly  transition  to  the  oost-deplovTier-t 
support  activities. 

To  ensure  i nteroperaoi 1 i ty  and  compatibility  between  AFV  ano 
other  automated  and  communications  systems  required  under  t“'e 
ACCS,  aviation  other  programs. 

Support,  plan,  recommend  actions  for  vehicle  electronic 

integrati on. 

Integrate  communication  and  command  anc  ccnt-ol  = /stems  in  S'.ccc^t 


of  AFV. 


-no VI de 


'.ecessarv 


i  ^  »v 4  u.  • 


wor(:ing  group,  .ogistics  ana  MANFF.  INI  worJing  grouds,  rs'/iew 
associated  plans. 

Facilitate  the  integration  of  Built  In  Test  (BIT)  into  planned  AFV 
diagnostic  capabilities.  Plan  for  required  Test  Maintenance 
Diagnostic  Equipment  (TMDE) .  Strive  for  commonality  and  design 
for  testability. 

Strive  for  Common  Soldier/Machine  Interfaces. 

Capture  mission  unique  requirements  and  equipment  into  the  AFV 
program. 
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21)  Support  AFV  Proo-f  o-f  Principle  Phase.  Capture  Operational  anp 
Technical  Demonstration  data  o-f  AFV  candidate  components  and 
suPsystems. 

22)  Maintain  AFV  Technology  Assessment. 

RESPONSIBILITIES 


The  ACRWG,  when  authoriced  by  the  Director, 

a.  Prepare,  coordinate,  and  update, 
1  terns; 


IS  responsible  to: 


as  necessary,  the 


■following 


1)  M  complete  CRMP  -for  the  AFV,  whicr.  will  eg  continually 
updated  throuqnout  the  AFV  li-fe  cycle. 

2)  Dra-ft  comeuter  Engineering  Support  Agreements  -for  the 
Director. 

3)  CDRLs  -for  acquisition  o-f  the  system's  computer  resources. 

4>  Computer  Resource  Management  (CRM)  sections 

speci-f  ications. 

5)  CRM  and  Comm.unicati  ons  technical  issues. 

c)  ''oT.pl  1  ante  chec)list  nor--ecct :  s.c  1  s  I  s  '  -  .  '  1 1  s  1 1  s'  s'c 

I  terns. 

T)  updated  hFV  management  clans  cc  e's.--e  s.tC''ati:^  S'C 

communication  resources  are  accuratel  y  co'^t'-a  .-sc  sne  ‘■ecei-.s 
necessary  emphasis. 

8)  AFV  Technology  Assessment  updates. 

9)  AFV  component  or  subsystem  test  reccts  eng  nilestcne 
revisions. 

b.  Advise  the  Director  and  Tas)  Force  on  gene’^al  colicv  rr?tte’'s  a’O 
on  speci-fic  computer  and  communication  resource  issues  applicaole 
to  the  -family. 
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c.  Provide  recommendati ons  and  advice  to  the  Director  on 
communication  and  computer  resources  technology. 


d.  Review  the  system  computer  resources  activities  for  compliance 
with  provisions  of  applicaole  DoD/DA  policies  and  procedures. 


e.  Conduct  impact  assessments  and  analyses  for  the  Director  in  both 
♦echnical  ana  managerial  areas  relating  to  automation  and  computer 
resources  of  the  AFV. 


orogram.  Identify  real  or  potential  proDlem  areas. 

6.  PROCEDURES 


The  ACRWG  will  be  convened  at  the  discretion  of  the  ACRWG  Chair.  Meeting; 
will  usually  occur  th-ee  times  yearly.  ACRWG  meetings  are  usually  one  o' 
two  davs'  duration.  ~hev  are  working  meetings,  where  r.ans  anc  sc'^edules 
are  creoared.  coo-'cnacion  meetings.  where  plans  o--soa-9P  b,  me;Tice’'s  C' 
ACRWG  audco.Tini  ctees  are  integrated  :"Cg  tna  c.s-'all  a.-scs*:  f  a 
c cmc  1  nat  1  C'^  c*  cne  c»-.c.  See  A^ne''  R. 


DISTRTBlJ-^IO: 


Dissemination  of  material  generated  by  the  ACRWG  will  be  accomplished  by 
the  chairman  in  accordance  with  a  distribution  list  coordinated  wi 


Program  Manager.  Minutes  of  ACRWG  meetings  will,  as  a 
distributed  to  each  of  the  member  agencies  within  ten  worimg 
meeting.  The  AFV  ACRWG  Mailing  List  is  provided  in  Appendix  C. 


8.  ACRWG  Charter  Administration.  The  charter  will  be  mai 
Appendir.  C  of  the  Computer  Resources  Management  Flan  py  the  AFV 
and  can  function  as  a 


function  as 
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document 
on  DA 
directly 


.  Recommended  changes  are  encouraged.  Mail  recommended  changes 
Form  2028,  Recommended  Changes  to  Publications  or  equivalent 
to  the  APV  Task  Force,  DAMQ-AFV-M,  Fort  Eustis,  VA  23604-5597. 
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Name  Organization  (Q-f-fice)  Address  w/Zip  Code 
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AFV  AUTOMATION  •!/  COMMUNICATIONS  WORt-.ING  GROUP  MEMEERS 


Poi  r,t  5  ( 5 ) 
2-f  Contac; 


Looarion 


Cc.'n.Ti/ 
E;;tl  /  E:: 


joart  D.  Buckstad 


.a-^'aa  -i"z 
r''‘‘ .  .’act:  Bvers 


i.'Cn  uactscn 
E-ECIS,  vA 


c'.'.’i  Z.  1  =:  a” 

A  /aoLiaAl  a;:  arc:' :  a  . 


1 AiO/ lAta 


SMcAa— F5z~5V 


A-rsc- 


Vung 


Cct.  Da '/a  “'riCa 
let  Stave  0.  =apca; 

Me;  Iscar  Ccacpei 


Picatinr.y  ArsanaU 
Dover,  NJ 
It  7  £06 -50  00 

Ft.  kno::,  ky 
A'0 121 -50(00 

-c.  _eavenwo-f, . 


Av;  £50/ 

1 20  i ) 
7947/ 

Av:  ^£4/ 
(502)  c2- 
175I)/ 


S^CHE-CI 


Maj  M:t'a  -aw-vi  aK 


’’r.  Se-:  Stctlar 

■tr.  P'coarc  Svctincnari 


Ft.  Leaverwer tn ,  t 
O6027-53I-0 

-t.  Laavanwc'-f' ,  - 


IcET'_-T2-£,  Ait  Ft.  Foivoir,  OA 

22060-3546 


Ict(P,'  Dick  ko*  +  rinke 


1 L?z"i 


—  33C:iN 


Ac ere  Prv  £d ,  MD 
21 0.05-500 1 
2S00  F  ewee'"  ■'1  1 1 

iCt-tei  3-1 ;  ,  t’O 

75--- 


■t.  Lee,  VA 
::30:-6000 


2791/2792 
Av:  2^5/ 
(701;  2^5 


Av:  6S'/ 
(SO'4)  77; 

Av;  ■’Aa/ 
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AFV  AUTOMATION  &  COMMUNI 

CATIONS  WORDING  GROUP 

MEMBERS 

Command , 

Points (s) 

Location 

Av/ 

Q-f-f  ice 

Dt  Contact 

Comm/ 

Extl/E 

GTEA 

’PD 

5300  C  0 i umC 1  a  R i k  e 

Av:  CE 

CSTE-CA-E 

Fails  Church,  VA 

'202) 

22041-5115 

/ 

^'”"9  E.:  Ot-f 

Mr,  Dick  k oval 

Hexagon  Building 

Av; 

AI*1CPEj-CC3 

Mr.  Jce  Kernen 

Ft.  Monmouth,  NJ 

[  20 1 ) 

07703-5000 

2C77/ 

pr-g  E;:  Grr 

TED 

Hexagon  B u 1 1 o i n g 

Av:  9' 

AMCPEj-CCr^T' 

Ft.  Monmouth,  NJ 

;201) 

07703-5000 

/ 

SISCEN 

Ma;  Ecgar  E.  Burroughs 

Av;  7; 

A^ZH-CDA 

Ft.  Gordon,  GA 

(404) 

30905-5090 

Z  c  'j  /  ■ 

"ACQM 

Mr.  Curt  Adams 

Av:  7: 

AttSTA-PVE 

Narren,  MI 

(313) 

43  u9  '  — 

8530/ 

■^ACO?" 

Mr.  Carry  liler 

Av:  7; 

Ar"3’'^‘-ZE- 

i^arren,  MI 

,  '  -  ; 

4039’ -5000 

S595/ 

TEGGM 

Mr.  Ecward  A,  Cheney 

Av:  2' 

AP1£TE-"E-G 

Aoerc  Prv  Gd ,  MD 

(301) 

21005-5055 

4  2  33/ 

-RACCC 

Mr,  Douc  ‘^'ointer 

Av;  6 

ATCD-:: 

Ft.  Monroe.  VA 

fonc  . 

23 ;5 1-5000 

3433/' 

T  r  A  Z' * 

Zr*  Ksn*,  'ZZI 

Av;  3 

_  V  wJ 

'•’r.  ■.vill:  am  Jones 

-t.  hc'-'rce.  .’A 

E04 ' 

1  ^er  • 

-- 1  ’ 
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AFV  ACRWS  INTCFJIATIC'N  A®  SUPPORT  -EISER'SHIP 
(ACRrO  Role:  X=^r,rer,  3=SjpDort,  I=InForitaticn) 


.DffiiTiiT.C » 

Z**!!?,  Titls 


:-  -t.  Flies.  'X 

Oor.rao  je.-elcc^e'ts 


t*  .o.*£io:;  -rv  '.  j-  -:.  i.s 
:-‘i:s  :•  "s 
ar;  -n,;  r. 


7oc;i-5(X)0 

Zot  Fl9tS^^ 

Or;  “:El'ov 

9y::-5X''' 

A,  S^c'c?  Z^rt 
Zz"  •Z'jrj^n  r^’CCKS 

"5  Rcoe'’t  J.  So-oel 


ACRhS  AL'.ovco/Zofflriercial  'eleor.cns 
Role  bitl/ErtZ 


Sv;R7S/ 


ZA'‘0-A-v-Z 


:-'i"Q  »('■•■■  O'’:  NAj  Toonas  Rozaa,': 

:'Ra;Ninp  iKor-.ir.c  Srsuos: 
i'v  Zoo;::  Ze.'5.cose".5  Zc.  Steo'ier  Inian 

■'a-.svs'  «c''  ;':  Z':.:  -TZ  A',oe'"5  Aacla.oi 

'93:  l':T':''3t.  :-'■  ».'>  Z^oj:  -ooert  Nette 

•  Tes:  Ir.oro'atio"  wr.;  So- 


"C- ;  ■;  S'O-O 


-a*’.tC'.  T.  a,’;;:’' 
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AZF».".  -'s'sst  Z*-i;£' 


.  -  a  _  -  .  9_ .  r 


♦♦  Zc.Tiir.a,"c;  -'1.  -■*■  y.aocc.  Z 

A'*C-T-AVD  Aviation  ’'rairin^  Zeviies 

A,’‘,Zr*'-SFZ  G'ound  Forces  Tramirg  Dev 

AiTCF'^-T'O  'rainirc  Devices,  'RAZE 


TSD 


rj 


♦»  Zomran-O;  A'EAA  Ace’'c  -■'v  3d,  TD  ZiyZ 
A''5>-D  •ac?''10l  Svs  Anaivsis  A;*.ivitv  tSD 

A^XE'-c  tace^ie.  Srs  Ana.ysis  Activity  'rD 


«  Zcoita-O:  ARZEZ 
irZAF-ZZ 
3'ZAF,--5 

;»i'c:_rcr-a'^ 


Dove',  NJ 


. , cOc"ZvvO 


.ortrc.  cvstSfTS 
yZlZ  Deve.oore't  Z‘*.:e 


"AZ.  Zaires  Ae'^ncc"! 

'.r.  ^a,-r,  1^-,-. 
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Dar.mana , 
Ot-fice,  Title 


ACRWG  Au'ovor./Co.'i.ercia:  leleEnone 
Role  EKtl/Ext2 


♦t  Coffioano:  ARI  Alesancria,  VA 

22333-iXiOl 

-'ERI  Ar«Y  Researcn  Institute 

ftr.  Ray  Sioc-rsLv 

I  Ay: 

284/ (20 

2) 

274 

9046/9135 

♦♦  CoiMianc:  PF?*SCH  -t.  luic;;,  ^.V 

AOlZI-jiX'O 

ATSB-CD"?t- 

Cot  Dave  p’-ide 

X  Av: 

464/ (502) 

624 

1750/55C5 

Cot  Steve  C.  Pauoas 

**  Cofficanc:  AR“SCK,ARI  "t.  ^;r.o",  Kf 

AaiCl-S-vOC 

'ERI-IK  Army  Ressartn  Institute 

"!5.  Earoara  A.  Black 

I  Av: 

464/ (5C 

2) 

624 

2613/6923 

♦♦  CoBBano:  ARQ  Researcn  Tr;  P-t,  N. 

127709-2211 

SICRC-DD/EL/MA  Arny  Resea'’cn  OrPice 

Lr.  Green 

I  Av: 935/ (919) 

540 

3331/0641 

f*  Ct.tffiart:  A’SC  Ft.  Eustis,  VA 

;:-604-5S97 

-'■^IC-DrD 

VBD 

I  Av 

92:/(BC)4) 

S7E 

♦*  Coamanc:  AvIACEN  Ft.  Rucker,  a. 

't-TiC 

aT2^'H*'L“X  T-'l-'  H) 

ta.* .  V 1  *  De  1  ash  aw 

NA 

:  Av 

558/ Cf 

25: 

'^•AC  /7C,’-- 

CoMinc:  AVSC3f!  =t.  Louis,  flO 

6:i::M798 

A^1SAV-^'S 

tr.  Cria,'‘les  J.  ‘rill 

1  Av 

693/::: 

4) 

263 

1C74/1C75 

tlr.  A.'thu.'  W.  Linjberc 

**  uct^ia'j!  r-I'EZ  "t.  seivoir,  VA 

22060-Cs'j6 

E’REE— 2  Efi'/cir  RZ  aro  £r^g  Centi' 

tr.Ecwa.''3  -.  Eic.-elt 

Jen* 

I  ~  / 

-1-  ' 

- 

rr4 

Z-'-’’-'-- 

♦♦  lor'S'i;  ZaZ  -t.  weive-^c'tn.  -E 

;c:z'-!zr; 

-  ------  . -;-t:'rtr 

; 

“ 

:r- 

:::: 

-'Z.-ZiZ-A  :z:  Zi',  >trg--s:i:-  :'s- 

r  15:="  l."5::i. 

::1  ' 

-Z:Z 

a'Z_-ZaZ-ZZ  ZZI  Zi' 

-  r  r  • 

m:  ' 

- 

:  1: 

a*Z.-.A.-I  ZZI  Zir,  lEW,  ABAS 

“a;  *^nne  Raracazne" 

I  -V 

111.'  '  ^ 

'  ; 

5:- 

A'ZL-ZAf*-;  fat  Int, 

^r.  Bsn 

;  Av 

cr  -  /  ; 

Nr.  RoOert  BuckingnaB 

ATZL-TAS 

CPT  DERR 

Maj  MAYES 

I  Av 

w52/(9 

3) 

654 

:a95/3A45 

♦+  Zoinoano:  ZACDA  Ft.  Leavenworth,  k,S 

66C:7-S:5C 

AT2L-CAN  ^^ateriei  Integration  D'.'e 

:t.  TED 

I  Av 

c  e  -\  /  /  5 

7  : 

6:4 

/ 

M  Zonaarc;  CATA  Ft.  LeavenHO’’tr.,  f;3 

66027-520<) 

atzl-tas 

Cot  Sam  B.  Humes 

I  Av 

!52/(9 

Z) 

c34 

Z4?5/:Ai-: 

♦♦  Ccwitanfl:  CEAZ  Washington,  DC 

20324 

ca::-fd 

TBD 

I  Av 

/'::o2) 

/ 
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AfV  ACRW6  INFORMATION  AND  SUPPORT  fSMBERSHlP 
(ACRWG  Role:  X=Me«3er,  S=Sup(Jort,  !=Inloritat'.on) 


AORrS  ALtcvcr/Oonae'cial  Telei'xe 
Role  £/tl/L':t2 


♦♦  CoT'i'ifl:  CECOM  Ft.  Belvcir,  VA  22060-5677 


ArZPM-NVD 

Night  Visiofi  Devices 

TBD 

S 

Av; 254/171:; 

aoA 

/ 

AMEEL-nD-VV 

Nignt  Vision  ?i  Electro  Ectics 

MAJ  Sutton 

s 

Av:  2:4;' 'TOD) 

6:4 

142A/ 

**  Co.'isaanc:  CE22M  -t.  Leavenwort',  *‘.3  66v 

27-52'lC 

’BD 

s 

Av::5;/'^1!, 

iSA 

C^T^'.ait:  2EC2 

hi  "t.  tanreutn,  NJ  077 

02-5000 

AMC-’‘-?t305 

Miilti-Service  Coot.  Evst. 

T5D 

c 

Av:  /:20'.; 

"iQDile  Sufiscn&er  Ecjio®ent 

T5D 

s 

Av;  /IDOl) 

/ 

A^CFI^-i^SE-ATC 

Mobile  Stibscrioer  Ecuioaent 

TBD 

: 

Av:  ICOI) 

' 

“'os  Location  Resorting  Sys 

’’BD 

3 

Av;  /(201) 

Satellite  CoMoni cations, 

TBL- 

T 

i 

Av:  /;:oi) 

' 

Field  A-ty  Tactical  Dta  Sys 

TBD 

5 

A^;  /!201) 

' 

TM5E  rodernication 

'BD 

5 

Av:  /IDOIJ 

• 

Autcoatic  test  Scooort  Svs 

TBD 

c 

Av;  /;20i! 

( 

"eat  F'^ogra*  Sets 

*5D 

c 

Av:  /!20ll 

Coeratiors  Tact  Data  Sys 

Mr.  Frsr..-:  Ninnen 

z 

92'' '  2’V  1  / 

DvAE. 

Mr.  Artnur  Moody 

■^est,  Measureaent  Si  Diagnos 

John  Winter  or  H. 

5 

Ay:-?2/::oi) 

C'**' 

42C^'/11-' 

WneelerSee  AMOTM-E, 

Mr.Lindauiit 

AME-M-C'AF:: 

Single  2han.  Groono  Ai'  Radio 

Lt.  Betti  Tallisan 

= 

A.: -'5/  '201; 

f  4ii 

.'.'I" ' 

Eaar.i'c;  ZE2'! 

^t.  Moncoutr. ,  nG  071 

Z03-50-)l 

A-EE.-'2: 

*ecT;ical  Director 

If.  2air-ji 

. 

A  ;  Dll' 

-Vi*'  : "  •, r  ' 

“C'/a'ce:  Eva  r  Iccects  “-i; 

;a  j'.  -coe't  .—istia- 

:-A 

TIT:  ::=E 

_  .  . 

_ 

----- 

ziZz?Zf*:z" 

■  r  ,  ^  . 

w  t  3. i 

j" - -  _  ^  _ 

*3---^  -  IZ*'*  Z. 

'Z  '*:•  r  '»?'■  = 

:  I'  z'l 

'ar.  lice- 

-'^n'^rq^r  Ni-»* 

'£  i  ..rzS** 

Avi^^: 

C  •  ' 

^  Ecr,:?,ar,c:  ZZL', 

jM  ASaD  ii.ar''enton ,  VA  22 

1S6-5100 

A.*'5E..-,R1>-3W 

Signal  Ne-rare  Ce-nter 

Mr.  David  Uaidman 

= 

-v; 2AA/ 

o'.:!' 

Compare;  2HZMS2H  *t,  MiCleliar,  AL  Es 

205-5030 

A'ZN-:v;2:c4; 

ww  b  L  •  •  w*  inc- ' « ^  ^ 

■ 

-V :  ztl> 

*-*  2:mnaf3;  2!E 

►Qr*  20 

■’cr__c '  i  c 

ATsy-:: 

Dcfoa:  Itenti'icatior  Eys 

Del  Billy  K'r.e 

Z  y  '  ^ 

•  7 

32":  ri'" 

Ficnarc  Z^il-ress 

**  Ecraand:  2IS 

,.AB22“  Mrt-'^at  A'^B,  On  A5 

423-5  ">7 

ASD'AEI) 

Joint  IF-  Sys  Prog  C*^ice 

TBD 

z 

A,:'E; 

-c; 

tty.  1 1 

XV-C-16 


uncussifie: 
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VtLUflE  XIV  APPENDIX  C 

AFV  ACftWS  INrORMATION  AND  SUPPORT  MEMBERSHIP 
(ACRNG  Role:  X=fie«der,  S^Supoort,  I=In*ori»atior) 


CofflsaoP, 
'DPPice,  Title 


A2R»5  Autovon/CoMercial  Telepnone 
Role  Extl/Ext2 


Cofiraar.d:  CSTA 


Aberti  Frv  Ed,  MD  21005-5059 


3T£2-C:-FC 

DofflSat  Systeffs  Test  Act: 

vity 

Mr.  David  C.  ZuoKo 

I 

Av::r?3/(301) 

278 

45^2/3647 

Mr.  Wesley  Swank 

iHi  Cocoand;  DA 

Washington,  DD 

:031'>-02:XA 

DACS-DMA 

CCS,  AI  Center  oi  Excel’ 

or^r  o 

Ltc  Anccnaton: 

Maj  Peterson 

T 

Av: 224/ (202) 

6713/6907 

Loffiw^riu*  uA 

Co 

20310-0653 

DALO-LEI 

TED 

1 

Av:  /(:02) 

/ 

DAMC-FDC 

DDCS2PS, 

TBD 

I 

Av:  / (202) 

/ 

DAMO-fDY 

QDCSCPS, 

TBD 

i 

Av:  /(202) 

/ 

DAMO-FDZ 

QDCoOPS,  Combat  Sarvics 

Sot 

"BD 

I 

Av:  / (202) 

/ 

DAMCHiJSZ 

QDCSCF'S 

TED 

T 

Av:  / (202) 

/ 

DAM3-FDS 

ODCSO.^,  Seats  and  P’-ograss 

L'C  Laticki 

T 

1 

Av: 223/ (202) 

22t}(}/ 

SAIS-AD 

DC=C4,  Archit  !<  Integration 

COL  Griope 

T 

Av: 224/ (202) 

694 

i.erc  / 

LTC  T-avis 

SARD- TV 

ASA-iFD'A)  Organization 

Mr.  Jia  St exert 

T 

e94 

=432/ 

DAMQ-FDD 

CDC5QPS,  CofflSat  Maneuver 

u*C  Paul  Ftasnik: 

T 

Ay:227/'2;)2) 

5^43./ 

LTC  Milne 

SARD-TR 

A3i-'RDA)  urgenioation 

hr.  Bruce  Ziraraerman 

I 

Av: 227/: 202) 

694 

•'ccq  / 

♦♦  CoiTiir.ant:  DMA 

St.  Louis,  MO 

6311 

18-3399 

Janeiro  -cenev 

Mr.  Rcoert  Smith 

• 

Av:693/(3;4) 

263 

423')/ 

♦♦  '_y^,r.src’.  I"'- 

^ED 

- 

^■3-c*cz  ^,3“^;""  ‘-’^9'Cy 

* 

-  «• 

“AJ  E'l:  -rtt: 

.c;-. 

Cca.Tvanc:  S'D. 

.  t.  •  .  lO  M  ■  <•.  .  1 

>3-530: 

S'l-CET".  /  ^ 

Ml  rmo '  O'**  1  r  Q 

Maj  Kevin  lagan 

Mr.  Ed  Hakin 

T 

A/:  99:/ COD 

544 

. 

«  Cofflfflano:  ETl 

Ft.  Belvoir,  VA 

22060-5546 

rcci-i^_T[)-r 

CPT  Williais  Foshay 
oFfice:  C££’'L-TD-S,  Alt 

X 

Av;  345/ (202) 

•cc 

2''91/279; 

::eet.-td-s 

Mr.  Thomas  M.  Cox 

I 

Av:  345/C0':) 

3023/ 

♦♦  Cociaano:  FAS; 
ATSF-CD 
ATSF-DVS/OA 


H  Ft.  Sill,  OK 
Coatat  Developments 


73503-5001 

TBD 

MR.  DALEY 
MAJ  HACDY 


3  Ay:t39/ 

I  Av:63?/ 


XV-C-17 
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VtlUfE  nV  APPENDIX  C 

AFV  ACRWG  INFORMATION  AND  SUP^'ORT  rEMSERSHIP 
(ACRVI6  Role:  X=Heffloer,  S=SuaDt3rt,  I=InForiMt;or) 


Coot, and , 
OtTioe,  Title 


M  Ccn-na-’c:  -AIDS  ScFt  -t.  Sill,  OK  7:50:-C0Cl 

AMC=*--3  TpO 

^'’v  zZ%  21 '/.-S" 5001 

3_r?"Z“2C  II  3Sc  lO/SDct  Dl  ^■BrtC.''2*5  I.C^  Ki>**'“lPne 

S.C-E-CC-J2  H'jfiao  E’'g.  Lao,C3  Mooellioc  Mr.  Sy  Steiroerg 

?..CHE'CE  Coooat  ae^vi:?  aoooo’-t  Oir  'sD 

£.:-E“5  -lalc  SLOOort  Oir  'EC 

■M  CcoBand:  HE-.'-ABCCM  Abe’^d  Prv  Sd,  MD  21005-50C1 
SLCHE  (RTEB)  Robotics  Teen  Ease  Erox  Mr.  Charles  Snoeoaker 

♦♦  Cowa.nc:  H3C,  AH3  ^t.  Sao  Houstor.,  'X  75234-5100 
HS-A-CDM  Acaaeff.y  c4  nealtr,  Ecieoces  “la;  'Ir.t 

**  Cooraaod:  INFSC'-"  -t.  Esorinc,  EA  31905-5400 
i*Er-:D-''.E-E  ir-bl;  E-sitb 

Ma:.  -ic'.a-:  k.  rt-;:n?v 


^  IK'^ELSIH  "t#  Isvsn.s, 


'ED 


‘C:  .N  "t.  Ruacbuca.  Ai  w5al*--'0'.'0 


.C'.T.i'-.C;  -CS.C'l.  - 

3-3—-'  A*'E3,  A--  l-*c''  "p--  1- 


H  CoTTanc:  ^C3CEN  Ft.  Lee,  VA 
A'3L-Cj  CSSCS  [ieve.xiiient 

A'CL-r 
ATC.-E 


33601-6000 

Ma;.  Deny  StroOel 
'ED 
-2^ 


♦4  " *1' 

o^C^-^C  Air  3e^e-se  systems  'EC 

A'CF^'Ce  Air  Ce^e'se  3o:jr,a'C  R  Ccrc-ci  'EC 

('/‘ZPf^y  C-.aoarrai/FAAR  'EC 

Ar2P*'-*iE  r«l;i:ye'3’’:'jnd  .aser  Cesi  'EC 

AMw'-M-:^*  :*Ow«.ar  .  -be^*’aCEb  ^07i**  i  '.ay  zu 

e,j  -‘-'g  n--to*  5  *7“ 


hCRwE  Autovor/CcsEiercial  Teleoho.'ie 
Ro.e  Extl/E-ktC 


.  Av:539/ 


X  Av;293/(3Ci; 

2'3 

59^5/ 

:  Av; 296/ 1301) 

273 

b'id/ 

AviCFo/fTA’l) 

275 

5570/ 

I  Av.  295/ 1301 ! 

'^72 

5E--/ 

I  A,v:295/!3C1) 

27S 

5565/ 

;  AvrA^l/ISlC) 

7'5;/ 

1  Ay:535/'4';i 

3  "e  " 

, 

1  A/j  / 

-32 

rr. 

XV-C-18 


;E7/:3''4)  733  33: 

tE7.  '.E'.'i:  '32 

^C/  /  ■  C-.''*.  /  v-i. 


^'5 '  II  Eli 

-  «  ^  ~  -,C  i  "?  K 

'ia' :i:5i  3'6 
E73 

'•ic  I.:  :'o 


•r 


Page  fta.  6 

yNCL.AS3.i-i£D 

Oa/24/97 

AFV  crup 

19  AUG  87 

VOLUTE  XIV 

APPENDIX  C 

ArV  a:.RW6  information  and  SUr-PORT  !€“PERSHIP 

lAORWS  Role:  X=re«oef,  S=Suoport,  I 

^Information) 

CciMiand, 

ACRWG  Autovon/Comnercial 

Telecnone 

OPPice,  Title 

Role 

Extl/Ej;t2 

PATRIOT  "BD 

. 

Av:  746/ CCS) 

876 

/ 

Ar,Cf>r!-FE 

PERSr.ING  TBD 

T 

Av:746/12C5) 

876 

/ 

WTI-RP 

Tactical  Airccrre  TBD 

I 

Av: 746/ (205) 

676 

/ 

AKCP1-3T 

STINGER  'BD 

T 

Av; 746/ (205) 

876 

/ 

finCPM-TQW 

TOW  TBD 

I 

Av: 746/ (205) 

E76 

/ 

unisanned  Ae'ial  Vet. ties  TBD 

f 

i 

Av; 746/ (205) 

876 

/ 

♦♦  Zoffiianc;  “P3CH  -t.  rtClsllar,  P. 

ATZSi-mP^CCC 

'J3A!tPS-C3Z“DCD  Oat  Jcseah  D.  Ricr.arc 

I 

Av:S65/ 

3510/ 

»»  Ccffl/cand:  “P^A 

.exiagton,  -.Y  4(t511-51Cl 

AMT.DfVED 

Pat.  Rsajiness  5:t  Activity  y-.  Phil  Brooxs 

• 

Av: 745/ (606) 

29: 

4177/:i70 

“3.  S'eity  rouTig 

«  Carssanc;  Pis 

*  P'an  -S'jstcr.e  A'iS's! ,  iuOOc^T-otOO 

ATEK-TDN 

CW4  Hunter 

I 

Av:  /(2C5) 

B7o 

/ 

♦*  tjiMA';:  N3c 

wissni  ■"'ZlO' t  h  w  lo*25’.'0 

NsS-APG-G 

Natl  era.  iu'sau  Naj  Veac:' 

Av::2:/(:o2. 

ZT’o/ 

n  Co<wand:  NRDE 

0  Satick,  MA  017(>i>5015 

STSNC-A 

SIOPS  ■<  AFV  Develooif.ents  Ns.  Joan  Walker 

T 

Av:256/(6171 

651 

4624/ 

3'PNC-A3 

Natick  RDaE  Oerter  'OPT  David  Armour 

I 

Av: 256/(617) 

cc  •••  CC^** 

Nr.  Jam  A.  0'fe?*e 

♦*  GsMint:  ‘"G: 

2H  "'’v  'jCi  *^2  2l005”-2C'l 

Gj  *  — 

-itcat  'G: 

-  .'C" 

''r'zTZ'. 

- _C-  'C 

t 

:  : 

1: 

Cc.T.r.i":: 

Li  O'**  If/e",  NJ  07801-0.  A- 

Olose  Oorciat  Armaflents  TBO 

Av;3s:/ 

w  CofliaanC:  Prg 

Ex  Of*  EdgewooO  A’-senai,  PO 

AK?EC-><BC 

Chemical  and  Nuclear  Systems  TBD 

I 

Av:  / 

/ 

♦♦  Comaand:  Prg  Ex  04^  Ft.  belvair,  Vfi  220b(^-55y6 

WIFED-STATfllS 

Btd  At  Piiit  Oad  In*o  Ngit  Sys  TBD 

1 

Av::54/ 

/ 

**  Coimnanc:  ^'g 

Er  Or^  Ft.  Ponmo-Jth,  NJ  07703-5<Xyj 

frcpto-ccs 

Command  R  Control  Systems  Nr.  Dick  Koval 

X 

Av;  995/ (20 11 

5A4 

2677/ 

Mr.  Joe  Kernen 

AflCPEO-CO'in 

Communication  Systems  TBD 

X 

Av; 99j/ [201 ) 

544 

/ 

«  Coftcand:  Prg 

Ex  CtF  Huntsville,  AL 

A.m?E'j-CCM 

Close  ComOat  Missies  TBD 

T 

1 

Ay:  / 

/ 

"orward  Area  Air  Detense  TBD 

1 

Av:  / 

/ 

XV-C-19 

Bags  No. 
0S/2;/87 

7 

i 
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JNCLASSiFir.0 
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vGLurt  tl'j 

Aot'ENDIX  D 

AFV  ACRWG  IfFOEflATION  AND  SJF'FTRT  f1E.-:-ERSHIP 

(ACRW5  Role:  )(='tefflber,  S=Support,  I=; 

Into'-inatior) 

DoEcari, 

ACRyiS  Ajtovon/Coff.nertii 

0‘rice,  'it 

.e 

Sol? 

ArAED-'E 

F;''?  EiiOpct  EyEt®('5 

TBD 

1  Av:  f 

«■  Dcnaro: 

DV" 

Ek  D**  St.  LC'-is,  !T'D 

03120 

AT^iI-*S 

TP3' 

[  -v;  ! 

♦♦  Doffoano: 

&r^ 

El'  S'**  wi'rer, .  “I 

45397-50<)0 

A-fAED-EDV 

D.tss  Dot.oat  1=“.i:1e5 

'ED 

!  Av:  735/ ',313) 

57A 

AtA’ED-DE 

TBD 

1  n\ :  I'zzt 

574 

♦♦  Eo.toanc; 

3 

r.  -_:i  »a>-'er*3n.  VA 

:21E6-5100 

ATEr-ED-IEk 

Intel  1 'Eiectr  Ua’-^i's  Sys' 

tees  fir.  Rot  Ruth 

£  Av::49/ 

♦♦  CoiriiTiaKi! 

'•'*2 

E:'  j'‘*  aasriinctt'!,  DD 

2*.  wW*. 

ayOrr.-^M*] 

AM-unition  SyEtSiTE 

'BD 

:  Av:  /;202) 

A'^AET-'.NG 

rrjQinoor  5',.c;o,U5 

T2D 

1  ^v:  /(2('2l 

a,*!=e:--:e 

-ei.tn  Care  Evjtei>s 

*B3‘ 

:  Av:  /i2C2) 

♦♦  Dot.-a-c: 

“MC 

2'-  v*- 

"ETl-tC:? 

^'8“* 33 

"B3 

;  -v:6£7/i£04; 

3w^^'2r»! 

e;3 

3C40t-50?0 

^  I  '  wk/'w 

■jfioat  D'eve:ooi5e''.tE,  CCD 

KICK  Sietnik 

!  Av;  Tj.)/ (404) 

79  i 

«  It’rirt: 

;  T  * 

^-'C';5-CnC;;) 

t'*;’  — ";‘c 

--  -  - 

'*5'  £--32”  3. 

AttorCrt  “ill?'.  :-. 

-.■:TE;  '  a.;o 

“*3  • 

-I'*}:  -1*. 

'e: 

-  Z  .  -  “ 

-•  ; 

: : . 

-:.  Ee-  ! 

•.t-.Clr-;' 

Extl/£xt2 


"i-."  iiV.sr. 


4^  r r'^r'a'^2  J 

Cr.y'^3^/S 


TAC2“  hi-re'.. 


A:3i7-5‘>0O 


T3D 


J_U 


•  ^  M  ,  Al  - 


13 

a.“:='^->':a: 

Iv*';**^*  , 


EraAlev  .-;;E:!n;  Ve'iic.?  B 
*ar>  SvEt?^?  'C:(r:a:  ve^irles!  TBD 
^'Eav’v  'actica!  Ve*',;;'. ea  ’’BC- 

.;:‘t  A'lrcre:  e; 

..g“t  Bcssa:  ve";:.?5 
*1  Az’^its  'anf  SvEtET, 
ril3  Far.;ly  or  Ve-.icleE 
“1A;  Aora/ns  Tani 
rs'j  'inks 


"O 


.  rj 

TED 

TED 

'ED 

TED 


a:t.:a.  v=“;;:eE 


'BD 


XV-C-20 


Av:7B:'': 


uv;  ' 

-v: 

Av: 'Eo ' 
Ay;  'Eo' 


Ay.  'Esi 
Av ; .’  '^0 ' 


i'A 
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AFV  ACRNG  Ilf  OflJWTION  AND  SUPPORT  .lElfSEPSHIP 
(ACRWG  Role:  X=flefflber,  S=SuDport,  ^Information) 


;,ca«arc, 
Office,  Title 


ACnNG  AjtovDn/LoTj,er;iai  'aieonone 
Role  EKtI/EKtG 


ANCPff-TV  Tactical  Vehicles 

T5D 

T 

Av:786/(313) 

574 

/ 

ftlCPN-TVH  Comnercia.  Cor.strLi 

rtion  Eg  'BD 

I 

Av;756/ ;313) 

574 

/ 

AflCP!f-TVL  Light  Tactical  Ver,: 

icles  TBD 

I 

Av:7B6/ 1313) 

574 

/ 

AftSTA-RS  Roootics  Division, 

Te-ch  Dir.  hAJ  Leonard  Cgtorn 

r 

Av:7£6/(:;:; 

574 

/ 

AlfSTA-RvE  Vetrcnics  Division 

,  Tech  Dir.  Nr.  Curt  Adairis 

V 

A 

Av:736/ (313) 

574 

5330/ 

A."3TA-SVE!SAVA)  Std  A’-®v  Vefonics 

Aren  Caorit  Nr.  Don  Sarna 

I 

Av: 736/ (313) 

5'4 

6160/ 

A“3Tft-2IA  Advar.ceo  Svs  Com 

ceots  Off  Nr.  Carry  Iller 

X 

Av: 786/ (313) 

574 

1:93/ 

t*  Cofiwanc:  'I’ECOM  Aoerd  Ftv  5i 

A.r3TE-TE-C 

,  ND  21005-5055 

Nr.  Edward  A.  Cheney 

X 

Av: 298/ (301) 

273 

42:6/: 

Caomanc:  TRAC— LVN  Ft.  Leavpowo 
A'Cr-  TRADGC  Analysis 

'tn.  KS  O6027-5200 

Cot  Randy  Brown 

a 

Av: 552/ (913) 

6E4 

5::l/ 

ATRC-F3 

TBD 

• 

Av: 552/ (913) 

634 

/ 

*4  Cemmano:  TRAC-vlS"R  ^ihte  5cs  hlis 

Rng,  NN38(;«)2-5502 

Naj  David  Davis 

f 

i 

Av: 258/ (505) 

673 

A'lC-wSDR 

TBD 

T 

X 

Av: 253/ (505; 

6/5 

■' 

**  Cenaand;  TRADX  Ft.  hon-oe, 

ATCD-CC  C4  Directcrate 

VA  23651-5000 

Nr.  Doug  Pointer 

X 

Av:  650/ (504) 

727 

346o/ 

ATC0-C3 

Cot  Saoioie 

T 

i 

Av:690/ (804) 

727 

/ 

ATCD-=X  ADA  5-  -5  Automates 

;  ivstees  Nr.  Ebner,  -AADCCI 

T 

Av:s60/{S04) 

/  */ 

1 1  / 

Intel  j  If,.  AI-I 


Ltc  Filak,  ArATIS 
“.r.  n'lice’T.i.-. 
isalle’' 


I”,  Itnr.ttieli,  VA 
•ooile  Electric  -ewer 


H  Comnand!  USAISE-  Ft.  Beivoir,  VA  2206C^5456 
ATTN:  Info  Sye  Eng  Command  TBD 

TACniS  Tactical  rigst  In*o  Syetems  Col  KcFadder. 

flaj  Mac  Hooliins 


I  A\'; 


I  Av;  /  / 

I  Av::.70/(404)  54C  EPOO/T’al 
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disagreements.  Minutes  O'f  each  meeting  are  prepared  by  the  ACRWG 
recording  secretary  -for  signature  by  the  chair  and  distributed  to  each 
member.  The  minutes  document  all  decisions,  agreements,  and  actions  ai 


the  ACRWG  and  Pecome 

a 

part 

of  the 

cf  f  1  Cl  al 

file  on  the  system. 

Inaccuracies  in  the 

(T.  1  n  u 

tea 

should  De 

brought 

to  the  attention  of 

the 

Chair  ■‘or  correction 

o-f 

for 

addition 

to  the 

Action  Item  List 

for 

resolution.  Record  secretary  duties  may  be  rotated  among  the  members, 
“mutes  a  ACRWG  meeting  will  be  mailed  to  each  member  within  ten 

working  days  ct  the  meeting.  Review  and  formal  concurrence  will  be 
returned  to  the  ACRWG  secretary  within  30  days  of  the  ACRWG  meeting.  The 
■"ecommenoed  format  for  minutes  is  in  Anne;;  2.  Emphasis  to  the  following 
areas  will  assure  clear,  concise,  unambiguous  ACRWG  minutes: 

a.  ^':'ovide  recommenaati ons  for  resolving  the  problem  and  the  impact 
as  a  result  of  the  p-'oposed  ’■ecommendati ons ,  when  a  problem  is 
Cl  tec  or  implied. 

0.  r-'oviGe  an  impact  statement  as  tp  the  effect  of  the  proDlem(s)  on 
the  total  program,  i.e.,  slippages,  spare  parts,  manuals,  missing 
to'fsct  aware  rates,  missing  ICC  cates,  stt. 


2P6Ci-*-y  •^olluw-uc  actions  from  prior  meetings  and  tne  status  of 
those  actions. 
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UNCLASSIFIED 


UNCLASSIFIED 


AFV  CRMP 
VOLUME  XV 


'l  SEPTEMBER  37 
TECHNOLOGY  POINTS  OF  CONTACT 


APPENDIX  D 

Armored  Family  o-f  Vehicles  lAFV) 
Task  Force  (TF) 

Technology  Pomes  o-f  Contact  (POC) 


0 


D.  1 


UNCLASSiF! 


.-ii .%  .V  w.*,".*.'*.'  V 


•r\’  svr.N.v^.^.v-.-v 


AFV  CRMP 
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iOHNOLOGY  LREA 


UNCLASSIFIED 


AFVTF  POC 


1  SEPTEMBER  B7 
TECHNOLOGY  POINTS  OF  CONTACT 


'ELEPHONE 


.■V'.’TT.-iT.-Tr 

r 

f 

f 

f 


AP'^0'=' 


'"UBILITV 


■-O'^-LSICN 


SENbO=3 


MAJ  winter 


AADLAND 


_"C  AADLANO 


-TO  HALL  ISSEY 


(A)  927-XXXX 

(9)  !S04)  -  B7B-XXXX 

:d6:..'1464 

1 4tT/ 1 4c4 

-Tt:.-/  1*^64 


:'HALI"Y 


HUMAN  "AC‘'aR3 


LI  AGNOSTICS 
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Checklist  to  f^'repare  -for  Milestone  I/II  Review 


1.  Have  -feasibility  studies  been  accomplished  to  determine  that  the  use 
o-f  computer  resources  in  the  system  is  reasonable  and  justified"^ 

2.  Has  supportabi  1 1  tv  o-f  the  system  peen  taken  into  account'’ 

3.  Has  the  overall  software  cualit-/  evaluation  process  for  the  software 

development  cycle  peen  cefined  to  tne  ma;:imum  e::tent  practicaole”' 

4.  Has  an  acpuisition  strategy  been  formulated  and  documented"’ 

5.  Has  the  TEMP  been  developed  to  document  planned  tests  and  continuous 

evaluation'!’ 

6.  Have  the  following  areas  peen  addressed'!’ 

a.  Evaluating  approved  operational  concepts'!’ 

b.  RSI  (rationalization,  standardization,  and  interoperability)'^ 

c.  Organization? 

d.  MANPRINT  (manpower  and  personnel  integration)'' 

e.  Personnel  (mental  category  mix,  male-female  mix,  physical 
requirements,  and  special  skills)? 

f.  Human  Factors  Engineering  (HFEl? 

g.  System  safety  and  health  hazaros? 

h.  HARDMAN  (hardware  versus  manpower)  methodology'' 

1.  NDI  and  PIP  considerations? 

j.  Developing  system  testability  and  fault  diagnosis  or  isolation 
concepts'' 

( .  Considering  the  use  of  modul  ar  construction  ana  standard  parts 
and  components  in  the  design  concept"' 

1.  I  cent : VI  no  .T,a;or  items  of  suooort— ‘el  ated  nardware  and  software 
■'■eouirin^  Cevel  ooment  and  their  interoperaci  i  i  ty  recu: 'ement  s  ' 
n.  Est ac 1 1  Shi ng  svstem  rsedinees  ocject: /e=' 

assessme^'t  arc  recair' 

c.  Estaolishing  the  strategy  arc  goals  *0-  svsoen  s_,'-c=  sn; 
mobilization  capacity"' 

p.  Establisnmg  strategy  for  minimizing  system  vul nerab  1 1 1 1 y"' 


7.  Have  risk  areas  been  identified' 
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a  pf'e!  1  mi  nary  CRMP  tieen  prepai'ed,  submitted,  and  approved  by  tbe 
appropriate  aporoval  autnonty  prior  to  bolding  Milestone  I/II  review' 


Has  t“=  System  Reouirements  Review  been  accomplished 


1 C’. 


Has  an  aLitomation  and  communications  resources  working  group  (ACRWG) 
seen  estacl  1  s'^ed"' 
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have  all  ncr-sevel opmental  item  iNDI)  development  tools  an: 
aoclicatic"  sc*tware  oast  apes  been  i denti -f i ed"^ 


Has  all  go'.'e''niTiEnt  turnished  so-ftware  been  identified' 


14. 


Will  all  software  develooment  and  nardware  support  tools  be  delivered 
to  tne  LCSEC  as  part  of  the  contract^ 


Which  Ada  Probram  Design  Language  (PDL)  is  tne  contractor  going  to 
use"' 


Will  the  LD'SEC  (Tiaintain  configuration  management  of  tne  software' 
Are  proper  programming  standai^cs  being  used  for  development"' 


15. 


Are  the  standards  adeouate  enough  to  ensure  that  the  documentation 
will  be  adeauate  for  life  cycle  maintenance"’ 


Is  security  protection  required  for  the  software  and  narqware  in  tne 
bevel opment/mai ntenance  environment"' 
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'ces  necessary  to  support 


-I  or.  or 


■  1  “-5  cc.T.::- 1  etec  t  .e  001--;:=: 


22.  Is  tne  clan  *□-  system  testmc  adeouate" 


2".  Has  enough  data  been  gatnered  to  accurately  formulate  oucgeta’'y 
estimates  anc  program  scnedules  for  computer  resoui^ces'' 
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24.  Have  siring  and  timing  studies  been  conducted  to  determine  minimum 
spare  processing  time,  memory,  and  input/output  cnannel  activity'’ 

25.  Is  the  computer  hardware  a  standard  ISA  to  the  maximum  extent 
practicable"' 

26.  Has  a  program  language  been  selected  and  approved"’ 

27.  Have  so-ftware  support  issues  been  discussed  (i.e.  Government-provi aed 
so-ftware  support  versus  contractor  support)? 

2S.  has  an  Interface  Control  Board  (ICB)  been  established  to  address 
system/ subsystem  inter-face  requirements"' 

29.  I-f  prototype  software  is  to  be  used  in  the  Full  Scale  Development  or 
Production  and  Deployment  phases,  has  it  been  oeveloned  in  accordance 
with  the  computer  software  development  cycle  (or  tailored  protion 
thereo-f ) 

30.  Has  tne  System  Design  Review  been  comoleted? 

31.  Has  the  overall  approach  -for  con-f iguration  management  (CM)  of  computer 
resources  been  ce-ined"’ 

32.  Has  the  software  quality  evaluation  process  for  tne  software 
development  cycle  been  refined"’ 

33.  Has  the  testing  concept  as  specified  in  the  TEMP  been  refined"' 

3-1.  Does  the  TEMP'  aoeauately  identify  quantitative  end  demonstraol e  test 
objectives  (performance,  functional,  interface,  etc.)"' 

35.  Has  an  acprocriate  evaluation  criteria,  been  establii'ed  -or  testi'C 
wnethe'"  software  and  naraware  have  reached  a  level  c*  nati''it- 
acorcfiate  for  each  svstem  life  cycle  phase  a'd  fc"  croceeoinc  I'tc 
■t^is  r.  sxt  =  9"' 

36.  Has  the  level  of  need  for  independent  verification  and  validation  oeen 
accessedh 

37.  Has  the  CRMP  been  updated"’ 
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iS.  Have  all  outstanding  CRMP  issues  been  identified  with  a  plan  for  their 
resolution’’ 

'9.  Has  the  system/segement  specification  been  updated  and  finalized  to 
incorporate  any  comments  received  during  the  SRR^ 

•i!>.  Has  a  draft  software  reaui rements  specification  been  completed  taht 
documents  requirements  for  each  CSCI’’ 

•1.  Have  logistics,  interoperability,  and  computer  resource  proolems 
identified  during  the  Concept  Exploration  Phase  been  resolved  or 
mini  m,i  zed’’^ 

’2.  Have  formal  requirements  documents  been  prepared  (i.e.  reouired 
operational  capability  (ROC),  training  device  requirements  (TDR))’’ 

-3.  Has  personnel  equipment  and  basic  force  design  been  determined? 

•4.  Have  security  issues  been  assessed? 

r5.  Have  cost  estimates  been  updated’’ 

Has  the  acquisition  plan  been  finalized? 

■7.  Have  contractual  requirements  been  developed  tnat  clearly  define  the 
following: 

a.  Baseline  operational  servicing  and  support’’ 

b.  Peacetime  readiness  and  wartime  employment  objectives’’ 

c.  Time  phased  support  schedule  OD jecti ves’ 

(3.  Has  a  functional  failure  mode  effects  and  criticality  analysis  (FMECA) 
been  per*crmed” 


.  -a'-'S  c‘'it;cal  cnresholds  been  ailocatec  bc  bne  a. see*  a“b  E’-bs.ebem 

compatible  witn  RAM,  sa-et/  and  healbr  ccjerbi^ec’ 

'0.  Have  areas  requiring  intensive  application  ph.D  resoL'.rces  tb 
minimize  rish  been  identified’^ 

>1.  Has  a  mauntenance  concept  been  developed"^ 

i2.  Have  all  failure  modes  been  fully  documented,  with  soecific  corrective 
actions  identified  and  risk  assessments  performed’*' 
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Checklist  to  Prepare  -for  the  System  Requirements  Review 


1.  Have  trade-o+t  and  optimisation  studies  been  per-formed  to  evaluate 
alternative  approaches  and  methods  to  reach  system  goals'^  Is  the 
candidate  programming  language  Ada? 

2.  I-f  the  candidate  programming  language  is  not  Ada,  has  a  waiver  been 
granted? 

3.  Are  the  candidate  computer  architures  -for  the  system  one  o-f  the 
standard  Instruction  Set  Architures  (ISA's)? 

4.  Have  allocations  oi  security  requirements  to  particular  HWCIs  and 
CSCIs  been  analysed'' 

5.  Have  the  risk  areas  and  -factors  o-f  the  project  been  identi-fied? 

6.  Have  systems  interfaces,  communication  -functions,  personnel  -^unctions 
been  identi-fied  in  order  to  de-fine  the  requirements  -for  computer 
resources? 

7.  Have  all  essential  system  functional  characteristics  been  identified"' 

3.  Have  the  necessary  interface  characteristics  been  identified? 

?.  Hve  the  functional  characteristics  of  hardware  and  software 
ccnf iguration  items  been  defined'’ 

l-'j.  Have  design  constraints  been  identified  and  documented" 
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Chect.list  to  Prepare  -for  the  System  Design  Review 

1.  Have  system  requirements  been  completed  and  de-fined  tor  each  HHCI  and 
per  ’  r 

2.  Have  approonate  trade-cn-f  and  cptimiration  studies  been  per  +  ermep  to 
eval uate: 

a.  Alternative  approaches  and  methods  -for  meeting  E-'stem 
r  e  c'.i  1  r  emen  t  s 

р.  I'^e  e-f-fects  o-f  constraints  on  tne  computer  resc;.. roes'"' 

с.  Lite  cycle  costs  versus  operational  recuiremsnts'" 

d.  Pis‘s  in  computer  resources  due  to  untried  teohnol eg v" 

3.  Have  all  applicable  Type  B  ~  Development  speci t i cat ; ons  been  preoared" 

Have  the  tunctional ,  intertace,  quality  tacter,  special,  and 
qual 1 1 1  cat  1  on  requirements  necessary  to  design,  develop,  test, 
evaluate,  and  deliver  each  Computer  Software  Cent i cur ati cn  Item  (CSC I; 
oeen  adequately  described'^ 

Have  ail  intertace  r eaui r ements  between  CSCIs  csen  described  in 
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ARMORED  FAMILY  OF  VEHICLES  (AFV) 
INTEGRATED 

COMMAND,  CONTROL,  AND 
COMMUNICATIONS  (C3) 
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Document  *^is=:Qn  Critical  Compute-"  Resaurces  (MCCRs)  -  Initiate  MCOR 
Durvev'5'  that  will  document  all  Points  ot  Contract  (F'OC's),  hardware 
and  SQ-ftware  information,  and  related  diagrams  and  descriptions 
tor o..,c''out  the  life  cycle  of  AFV. 

Idert'.-^v  -e'^sc^nel /^ec"''' 1  c ?1  Shills  Needed  -  Tnrough  tne  use  of  the 
APV  survev(5;  and  other  sources,  identify  the  software  personnel 
needed  to  support  AFV. 

Create  a  _:prarv  -  The  ^DSEI  liDrarian  will  Pegin  preparation  needed 
*or  housing  any  incoming  documentation  during  the  AFV  life  cycle. 

Acquire  Partial  So-^tware  Personnel  Crew  -  Activities  at  this  stage  of 
software  support  will  reouire  minimal  personnel. 


Identify  Hardware  and  Bo-^twa’^e  Svstem  Components  -  Using  the  AFV  MCCR 
Survey'.s)  and  other  relevant  information,  estaolisn  a  listing  of  ail 
AFV  hardware  and  software  svstem  components. 

Identify  S'-'Stem  FuDDO’'t  -a'^dware  and  Software  -  'hrough  examination  of 
the  AFV  MCCR  SLirve'/(3;  and  the  id9nti*ied  system  conconents.  estaolisn 
a  list  of  all  5i;ooort  hardware  and  software  -eqLared. 


Acquire  Remainmc  ='grct-.ngi  -  Sather  aH  remaining  software  oersonnel . 

Atqji-e  I  cc  jmar,-_  a> ; ^;cn-ical  =  uo  1 1  Cat  1  0"  s  -  A-cui--e  ail  technical 
na.-'ua.ls,  duel '.cat;  cns ,  specifications,  and  ctne^  informaticn  related 
to  AFv  for  even*,  a  1  f-.  Img  m  cne  lCSEC  lio"-arv.  "^’is  will  0=  an 

f''sca''~e  :c-t-va''e  E-ccc-t  ^lan  -  A  seftwa-'e  s.^ccert  clan  11  ce 
c''eca''ec  tc  'aniliarire  an.-  new,  minimall'.  t-'a.inec  ce--  =  r-:^e;.  .-.it' 
ri-'.',  "^‘*"‘950  Will  00  --020  *"0  0'f*0c*  - 

D‘'c:9Cu-ea  .r  tne  sa.ne  manner  that  the  original  s-stem  encineer 
envisioned  supcort  tafi.ng  place. 

Familiaripp  ^'ersonnel  with  Svstem  Software  Con* i gur at  1  on  -  The  AFV 
project  engineer  will  provide  all  pertinent  information  to  software 
personnel  so  they  can  become  knowledgeable  of  the  AFV  software 
structure. 
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Prepare  LCSEC  Procedures  -  LCSEC  procedures  can  be  developed  once  the 
personnel  have  a  knowledgeable  understanding  o-f  the  AFV  software.  An 
outline  for  preparing  the  LCSEC  procedures  can  be  found  in  the  concept 
of  operations  guidebook,  availaole  from  the  project  engineer. 

Define  Space  and  Security  ^egui i^ements  -  Define  space  and  security 
requirements  with  respect  to  on-hand  resources. 


Prepare  Test  Cell  -  After  space  and  security  requirements  have  been 
defined,  an  area  will  be  designated  and  preoared  (including  power 
requirements  and  storage)  to  serve  as  a  test  cell. 

Acquire  System  and  Support  Items  -  Acquisition  of  the  System  and  its 
associated  support  harpware  will  begin  after  the  defining  of  space  and 
security  reouirements  for  the  test  cell.  The  support  software  will  pe 
acquired,  developed,  or  copied  if  available. 

System  Installation  -  All  AFy  system  components  and  support  items  will 
now  be  installed  in  the  preoared  test  cell. 

Develop  and  Conduct  Irtearation  F-'ocedurus  -  Test  procedures  will  be 
developed  and  conducted  to  insure  that  the  cell  is  operational  and 
simulates  inputs  as  required.  Test  results  will  be  revised  and 
documented  as  reauired. 


Develop  Conf iGuration  ^'anacement  (CM)  Plan  Anne::  -  The  CM  plan  anne;: 

will  define  manacenenc  practices  with  respect  to 

’■svi  51  on/conf  1  qurat  1  on  updates,  supervision  of  mod;  ♦  i  cati  cns ,  and 


.-ond'-.-C  E.sCr’’'  -s'^dware  ^’-aining  of  Fe'^scrnel  -  Cnee  fe  = .  stem  is 
1  “seal  led  in,  cno  i  =  cell,  Che  personnel  can  bedi’"  hancs-cn  c^ain 


1  "seal  1 er 


wicn  cne  ecuip' 


Cendudt  Software  Tssts/Emul ation  -  A  thorough  testing  and  emulating  of 
the  complete  system  will  be  conducted  at  the  stage.  This  is  the  last 
step  before  the  system  is  geared  for  LCSEC  procedures.  An  evaluation 
of  the  system  and  its  software  will  be  performed  by  using  a  software 
support  program  that  emulates  operation  of  the  actual  airborne 
system.  Operation  tests  are  performed  by  inputting  sample  data  with 
known  results.  If  the  results  do  not  match  the 


XV-H-2 


j  i  M 

Uiil 


CLASSIFIED 


934 

UNCLASSIFIED 


AAHOAED  FAHILV  OF  VEHICLES  <AFV>  AUTONATION  AND  4/4 

COHHUNICATION  AESOUACE  HA.  .  <U>  AAHOAED  FAHILV  OF 
VEHICLES  TASK  FOACE  FOAT  EUSTIS  VA  A  D  MJCKSTAD 
•1  SEF  87  F/O  5/1  NL 


UNCLASSIFIED 


AFV  CRMP  1  SEPTEMBER  87 

VOLUME  XV  LIFE  CYCLE  SOFTWARE  ENGINEERING  CENTER 


pre-determined  results,  a  problem  exists.  Testing  and  emulation  will 
continue  until  all  combinations  of  the  system  software  have  been 
verified . 

T.  Center  Operations  - 


A.  Management 

B.  Clerical  Assistance 

C.  Budgeting 

D.  Telephone  Commercial  Direct  Access 

E.  Paper  R^producti on  High  Vol 

F.  Local  Network 

U.  Develop  Continuity  Of  Operations  Plans 

V,  Administration  Preparation  -  Prior  to  staffing  administrative 
requirements  preparation  must  occur.  Technical  staff  should  hot  be 
overloaded  with  ordering  manuals,  equipment,  etc.  that  are  required 
for  day  to  day  operations. 
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A.  In-formal  Technical  Reviews 


o  System  requirements  Review  (SRR)  -  Here  the  government  and 
the  contractor  ensure  that  system  requirements  have  been 
completely  and  properly  identi-fied  and  that  there  is  mutual 
understanding  between  them  on  the  system  requirements. 

o  System  Design  Review  (SDR)  -  A  review  of  the  conceptual 

design  of  the  system  to  assess  allocation  requirements  and  to 
evaluate  the  contractors  overall  oevelopment  capability.  A 
preliminary  Software  Requirements  Specification  (SRS)  snail 
be  available  for  this  review. 

o  Software  Speci f i cati on.  Review  (SSR)  -  This  is  a  review  of  the 
finalized  Computer  Software  Configuration  Item  (C3CI) 
requirements  and  operational  concept.  The  adequacy  of  the 
SRS  will  be  determined  at  this  review. 

o  Preliminary  Design  Review  (PDR)  -  This  review  shall  be  held 
after  preliminary  design  efforts,  but  before  start  of 
detailed  design.  The  Software  Top  Level  Design  Document 
(STLDD) ,  Software  Test  Plan  (STP)  and  oreliminary  Computer 
Resources  Integrated  Support  Software  Document  (CRIED)  shall 
be  available  at  this  review. 

Critical  Design  Review  (CDR)  -  The  draft  Product  Specifications, 
will  be  reviewed  and  the  contractor's  product  baseline 
established.  The  contractor  will  present  the  results  of  their 
detail  design  effort  which  demonstrates: 

o  The  allocation  of  requirements  to  individual  modules,  to 
include  a  complete  module  input  and  outout  mapoing; 

□  The  estaol  1  shment  of  e:;act  inte-'face  r  el  at  i  c~.sr.  i  z  s  tetwee'- 
the  modules  and  other  orocrams  or  itema  zf  ez.io.-e-t  srz 
facilities;  and, 

o  The  organization  of  the  file  structure  or  cata  oase  in 

support  of  the  design.  The  CDR  marks  the  completion  cetailed 
design  and  the  oeginning  of  coding. 
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MILESTONE 


EXPECTED  COMPLETION 


1.  Computer  Scientist  assigned  to 
Task  Force  to  assist  in  computer 
resource  development. 


2.  Communication  specialist  assigned 
to  Task  Force  to  assist  in 
communication  development 

3.  Preliminary  CRMP  has  been  prepared 
■for  automation  and  communication 
resource  management. 


4.  Quali-fied  communication  and 
computer  resource  personnel  included 
in  the  Test  Integration  Working  Group 

(TIWG) 

5.  AMC,  TRADOC  review  o-f  CRMP 


6.  Designation  o-f  a  Life  Cycle 
Software  Support  (LCSS)  Center  for 
support  of  the  AFV  project. 


7.  A  computer  resource  working  group 
has  been  established. 


8.  Qualified  Army  CR  personnel  have 
been  included  in  source  selection 

teamls)  to  assist  the  Director  to 
evaluate  technical  proposals. 

9.  The  System  Specification, 

Statement  of  Work,  and  associated  DD 

Form  1423  (data  items)  have  been 
reviewed  by  qualified  Army  CR 
personnel  and  that  they  have  certified 
that  adequate/appropriate  CR 
requirements  have  been  incorporated. 


10.  Proper  data  right  clause  has  been 
incorporated  into  the  RFP (s) /contract (s) 

11.  Final  draft  CRMP  prepared  in  support 
of  DARCOM-R-70-16 

12.  HQ  DA  aproval  of  CRMP. 
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13.  Milestone  I/II. 

14.  Submission  oi  waiver  requests  for 
intention  to  use  a  programming 
language  ither  than  Ada. 

15.  HQ  DA  approval  of  waiver  requests 
for  use  of  software  other  than  Ada 

16.  Government  formal  certification  of 
AFV  computer  software  lAW 

DARCOM-R  700-34. 
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Military  Standards 


DOD-STD  480A 


DOD-STD  483A 


D0D-STD-490A 


MIL-STD-S81A 


DOD-STD-1467 


MIL-STD-’521B 


ANSI/MIL-STD-ia:5A 


D0D-STD-:i67 


Military  Soeciti cat  ions 


MIL-S-52779A 


MIL-S-8349(: 
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-■ODD  O^Dc.D 


DQDD  5000. 


DODD  5000.3 


DODD  5000.29 


DODD  5000.31 


DODD  5200. 1 
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Con-f  1  gurati on  Control -Engi neeri ng  Changes, 
Deviations  and  Waivers 

Configuration  Management  Practices  -for 
Systems,  Equipment,  Munitions  and  Computer 
Programs 

Specification  Practices 

Wort  Breakdown  Structure  for  Defense  Materiel 
I  terns 

Software  Support  Environment 

Technical  Reviews  and  Audits  for  Systems, 
Equipment  and  Computer  Programs 

Ada  Programming  Language 

Defense  System  Software  Development  Standard 


Software  Quality  Assurance  Program 
Requirements 

Specifications,  Tyoes  and  'crms 


■'rJOr  3»=te'T’  ~C  C.  1  51  t  •- 3- s 

major  System  Acci.  i  si  t:  on  F ’-cceC-.r es 

Test  and  Evaluation 

Management  of  Computer  Resources  in  Major 
Defense  Systems 

Interim  List  of  DCD  Approved  Hign  'Droer 
Programming  Languages  (HjL) 

DOD  Information  Security  Frccram 


XV-Z-2 


-.(oLASSIFiEO 


AFV  CRMP 
VOLUME  XV 


.1  SEPTEMBER  87 
REFERENCES 


lu 


IASS  IF!  ED 


Regulations 
AR  25-1 
AR  25-5 

AR  70-1 

AR  70-10 


AR  70-15 

AR  70-37 
AR  70-XX 

AR  71-3 
AR  71-9 
AR  380-5 
AR  380-380 
AR  700-126 

PafTichl  ets 
DA  F'amphlet  11-25 

DA  Pamphlet  70-21 

DA  Pamphlet  700-26 
Bulletins 
TB  18-100 


Army  In'formation  Management  Program 

In-formation  Management  -for  the  Sustaining 
Base 

Research,  Development  and  Acquisition  System 
Acquisition  Policy  and  Procedures 

Research  and  Development  Test  and  Evaluation 
during  Development  and  Acquisition  o-f 
Materiel 

Research  and  Development,  Product  Improvement 
o-f  Materiel 

Con-figuration  Management 

Draft,  Management  of  Army  Critical  Computer 
Resources  (MCCR) 

Force  Development  User  Testing 

Materiel  Objectives  and  Requirements 

DOD  Information  Security  Program  Regulation 

Automated  Systems  Security 

Acquisition  Program  Management 


Life  Cycle  System  Manacement  r^odei  lDSMM’ 
for  Army  Systems  (draft,  March  37/ 

Research  and  Development,  The  Coordinated 
Test  Program  (CTP) 

Acquisition  Program  Management 


Army  Automation  Life  Cycle  Management 
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Army  Battle-field  Inter-face  Concept  (ABIC) 

CRMP,  -for  the  155mm  Sel-f-Propel  led  Howitzer  Improvement  Program 
CRMP,  -for  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS) 

CRMP,  -for  Light  Helicopter  Family  (LHX) 

I 

Li-fe  Cycle  So-ftware  Support  (LCSS)  Implementation  Plan,  DAM0-C4L  Jan  84 
See  Append!;:  E. 

Memorandums 

DAMO-AFV-M,  7  July  87,  Subject:  Armored  Family  of  Vehicles  (AFV) 
Preliminary  Computer  Resource  Management  Plan  (CRMP) 

DAMO-AFV-M,  17  July  87,  Subject:  Armored  Family  of  Vehicles  (AFV)  command. 
Control,  Communications,  Computer  (C4)  Mission  support 

DAMO-AFV-C,  17  July  S7,  subject:  Armored  Family  of  Vehicles  (AFV) 
Integrated  Command  Control,  Communications,  Intelligence  (C3I) 

Gui  de 

Messages 

AMCDE-ATC,  dtg:  181630Z  Aug  87,  subject:  Armored  Family  of  Vehicles  (AFV) 
Preliminary  Computer  Resource  Management  Plan  (CRMP),  dated  26  Jun  37 

DAMO-AFV-M,  dtg:  'jCOS'iiOZ  J-jn  E'7,  subject;  ^irmo-ed  o-^  ^-’enicles  (AFV- 

Automaticr  and  'Icmmunicatian  Resource  won;  mg  5rouo  ■.Al'i'.ji 

AMCDE-SB,  dtg:  221-iiOZ  Me-.  £5,  subject;  ‘-“ji 

Field  Manuals 

FM  24-1,  Combat  Communication 
FM  100-5,  Operations 
AMC  Regulations 

DARCDM-R  70-16,  Management  of  Computer  Resources  in  Battlefield  Automated 
Systems 

TRADOC  Regulations 
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ACCEPTANCE  TESTING  6.13 

Access  to  Internal  Contract  or  Data  4. 1.1.3 

ACCS,  Li'fe  Cycle  So-ftware  Engineering  Centers  3.3.31.3 

Acquisition  Guidance  1.4.1 

ACQUISITION  MANAGEMENT  ORGANIZATION  AND  RESPONSIBILITIES  4.2. 
Acquisition  Strategy  4.1.1 
ACRWG  6. 2. 2. 3,  7. 6. 5. 2 
ACRWG  Functions  4.2. 1.2 

Activities  Required  -for  LCSEC  Support  7. 1.1.2 
Ada-Based  Program  Design  Language  5.16.1 
ADMINISTRATION  1.11 
AFV  C4  ARCHITECTURE  TESTING  6.9 

DEVELOPMENT  SYSTEM  METHODCLOGY  1.7 
Hardware  and  So-ftware  Maintenance  3.9.5 
Hardware  Development  System  Methodology  1.7.2 
INTERFACES  4.9 
LCSEC  Training  7.S.1 
Lite  Cycle  Support  7.2.1 

Logistics  Management  Working  Group  3.3.30.7 
Maneuver  Working  Group  3.3.30.5 
MANPR I NT  Working  Group  3.3.30.6 
Processor  Selection  Guidelines  5.20.3 
Retired  Board  ot  Governors  3.3.30.1 
Sottware  Development  System  Methodology  1.7.1 
STANDARD  CREW  INTERFACE  -  HUMAN  FACTORS  ENG  INNER  I NG  2.5 
Study  Advisory  Group  3.3.30.2 
SYSTEM  DESIGN  PHILOSOPHY  3.4 
Task  Force  3.2.1,  6.2.2. 1 
Test  Integration  Working  Group  3.3.30.4 
VEHICLE  CONTROL  AND  OPERATING  SYSTEM  (VCOS)  2.4 
Working  Groups  and  Boards  3.3.30 
Air  Defense  Command  and  Control  System  'AD'CCS)  3.3.32.2 
School  3.3.21. 1 

Systems  (Provisional’  3.3.32.1 
Ammunition  Logistics  (Ammolog)  3.3.32.6 
Aopendices  to  the  CRMP  1.9. 3. 3 
Area  Communication  2. 4. 4. 9 

Armament  Research  Development  Engineering  Center  (ARDE  3.3.^.  1 

Armament,  Munitions,  and  Chemical  Command  (AMCCOM)  3.3.9 

Armor  School  3.3.21.2 

Armor  Training  Devices  (ARD)  3.3.32.52 

Armored  Family  ot  Vehicles  Task  Force  (AFVTF)  5.2.1 

Army  Command  and  Control  System  (ACCS)  Interoperability  5.23.1 

Army  Command  and  Control  System  Intertace  2. 4. 4. 6 

Army  Communicative  Systems  3.3.32.53 


INDEX-2 


UNCLASSIFIED 


AFV  CRMP 
VOLUME  XIV 


uNCUSSIFlEO 


1  SEPTEMBER  87 
INDEX 


SUBJECT  PARAGRAPH 

Army  Information  Systems  3.3.32.7 

Army  Materiel  Command  (AMO  3.3.3,  4.2. 1.3,  5.2.4,  6. 2. 2. 4,  7.3.4 

Army  Materiel  Systems  Analysis  Activity  6. 2. 2. 8 

Army  Tactical  Missile  System  3.3.32.8 

Audits  5. 10.4 

Audits  and  Controls  3.9.3 

AUTHORIZATION  1.10 

Automated  Test  Suites  6.17.1.2 

Automatic  Logbook  2.4.4.17 

AUTOMATION  AND  COMMUNICATION  ARCHITECTURE,  RESOURCE  ALLOCATION  4.3 

Automation  and  Commuri cations  Resources  Prototype  6.17.1.1 

Automation  and  Communications  Resources  Woricing  Group  3.3.30.3 

Automation  Standardization  3.3.1 

Automation  Support  Facilities  4.12.1 

Auxiliary  Power  2. 4. 4. 2 

Aviation  School  3.3.21.14 

Aviation  System  Command  (AVSCOM)  3.3.26 

BACKGROUND  1.3 

BATTALION  INTEGRATED  C3I  ELEMENTS  2.3 

Belvoir  Research  Development  Engineering  Center  (BRDEC)  3.3.12 

BENCHMARK  TEST  CASES  6.15 

Black  Box  Testing  6. 5. 7. 4 

Black  Programs  .  4 

Boresight  Devices  3.3.32.9 

Bradley  Fighting  Vehicle  Systems  3.3.32.19 

BRIGADE  AND  HIGHER  C3I  ELEMENTS  2.2 

Cannon  Artillery  Weapons  Systems/JPM  Guided  Project!  3.3.32.10 
CCE  and  Selected  Materials  Handling  Equipment  (CCE/SMHE)  3.3.32.42 
Chemical  Demilitarization  (Provisional)  3.3.32.11 

Research  and  Development  Engineering  Center  3. 3. 9. 2 
School  3.3.21.3 

Clothing  and  Individual  Equipment  3.3.32.12 

Combat  Service  Supoort  Module  2.4.4.16 

ComDined  Arms  Center  (CAC)  3.3.4 

Commercial  Computers  and  Software.  4. 1.2.4 

Common  Computer  Hardware  Software  Svstems  3.3.32.13 

Common,  Standard,  and  Reusable  Software  Components  5.21.4 

Communication  and  Electronics  Command  (CECOM)  3.3.7,  6. 2. 2. 9 


INDEX-3 


JNCUSSIF 


AFV  CRMP 
VOLUME  XIV 


UNCLASSifiED 


SUBJECT 


1  SEPTEMBER  87 
INDEX 


PARAGRAPH 


Communication  Control  2.4.4.11 

Development  Constraints  4. 1.1.2 
Equipment  Support  Facilities  3.7.3 
Resource  Acquisition  1.8.5 
Standardization  3.8.2 
Support  Facilities  4.12.2 
System  Acquisition  4.5.4 
System  Design  5. 4. 3. 2 
System  Growth  4.10.5 
SYSTEM  TESTING  6.8 
COMPOSITE  SYSTEM  INTEGRITY  7.5 
Computer  Development  Contraints  4. 1.1.1 
Hardware  Design  5. 4. 3.1 
Hardware  Support  Facilities  3.7.2 
HARDWARE  TESTING  6.4 
PROGRAM  AND  DATA  RIGHTS  4.7 
Program  Configuration  Item  5.13.1 
Resource  Acquisition  1.S.4 
Conf i gurati on  Audits  and  Reviews  7.6.4 
Control  5.10.2,  7.6.2 
Control  Board  (CCB)  7.6.5. 1,  7.6.5 
Identification  5.10.1,  7.6.1 
Item  Verification  Review  (CIVR)  7. 6. 4. 4 
MANAGEMENT  5.10,  7.6 
MANAGEMENT  CONCEPTS  4.13 
MANAGEMENT  PLAN  5.13 
Status  Accounting  7.6.3 
CONTRACTING  STRATEGY  1.6 
Contractor  Organization  4.2.2 
Contractor  Provided  Documentation  4.11.2 
Contractors  1.5,5.  6.2.2.11 
Czmesponpance  T-acsacility  5.12.2.2 
IRMP  Recommended  Clianqes  1.12 
CrosE-^'eT ererce  Treceeoilit/  5,12.2.1 
Lata  Bus  Growth  4.1'!’. 4 
Data  Communication  2. 4. 4. 5 
DEFICIENCY  MANAGEMENT  5.8 

Def 1  Cl ency/ Improvement  Reporting  and  Processing  7.  fa.  6 

Department  of  the  Army  or  Special  Project/System  Office  3.3.33 

Deployment  Support  4.12.4,  7.2.5 

Design  and  Host  Facilities  5.20.1 

Detailed  Software  Design  5. 4.2. 4 

DEVELOPMENT  AND  SUPPORT  REQUIREMENTS  3.7 

Development  Contractors  5.2.2 


INDEX-4 


‘■-'•'CMSSiFiFn 


0* 


AFV  CRMP 
VOLUME  XIV 


I  SEPTEMBER  87 
INDEX 


I !  ?*  I  r-  •  •• 

Ui'iCuo: 


SUBJECT  PARAGRAPH 

Development  Costs  7.12.1 

Methodology  4.4.2 
OBJECTIVES  3.9 
ORGANIZATIONS  5.2 
Philosophy  3.9.2 
Planning  and  Controls  5.3.2. 1 
Procedures  5.21.3 
Proveout  (DPO)  Phase  2.6.2 
RISK  ASSESSMENT  3.11 
SCHEDULE  5.5 

Support  Facilities  4.12.3 
Development/Proveout  Alternatives  1.6.1 
Development/Proveout  Phase  1.4.3,  1.5.3 
DEVELOPMENT/ TEST  RESOURCE  REQUIREMENTS  5.7 
Developmental  Test  ?<  Evaluation  (DTJ-.E)  6.17.2.1 
DEVELOPMENTAL  TESTING  (DT)  6.11 

Director,  Armored  Family  o-f  Vehicles  Task  Force  (AFVTF)  3.3.1 
DOCUMENTAT I ON  ACQU I S I T I ON  4.11 
PLAN  5.12 
SUPPORT  7.4 

DT!<E  Personnel  Requirements  6.17.3.1 
Embedded  Training  2.4.4.14,  2.5.2 
Engineer  School  3.3.21.4 
ENGINEERING  PRACTICES  5.21 

Environment  Control  and  Li-fe  Support  2.4.4.13 

External  Interfaces  4.9.2 

Faci lities  6. 17. 2 

Field  Artillery  School  3.3.21.5 

Field  Artillery  Tactical  Data  Systems  (FATDS)  3.3.32.14 

Fielding  Costs  7.12.3 

Fire  and  Weaoon  Control  2.^.4.  12 

Pi 1  nder / Rembass  3.3.32.15 

Firmtsars  Acquisition  4.5.3 

Formal  Cual itioacicn  Review  (FQR)  7. 6. 4, 3 

Fc'^mal  ■^es’iinq  o.5.1 

Full  Scale  Protot'-pes  1.4.3.  1 

Functional  C3I  2.3.3 


S3 


I 


Configuration  Audit  (FCA)  7.6.4. 1 
Requirement  Testing  5.19.4 
CC3I]  Feedback  2.3.4 
Funding  1.3.2,  7.13 
General  Approach  5. 12. 1 

General  Officer  Steering  Committees  (GOSC)  3.3.31.1 

Government  Agencies  1.5.4 

Government  Furnished  Documentation  4.11.1 

INDEX. 5 

INDEX-5 


&.IOI 


AFV  CRMP 
VOLUME  XIV 


-.oSiFiED 


1  SEPTEMBER  87 
INDEX 


SUBJECT 


PARAGRAPH 


Government  Furnished  Equipment  (GFE)  1.5.6,  3.7.4 
Management  and  Working  Groups  3.3.31 
Organisation  4.2.1 

Growth  Capacity  and  Supportabi 1 i ty  5.7.1 
GROWTH  REQUIREMENTS  4.10 
GROWTH,  MODULARITY  AND  MODIFICATION  5.11 
Hardware  Acquisition  4.5.2 

Deficiency  Management  5.3.3 
Design  1.9.5 

Design  Methodology  5.4.3 
Facilities  5.7.3 

HARDWARE/SOFTWARE  TRADE-OFFS  4.5 
Harry  Diamond  Laboratory  (HDD  3.3.13.2 
Hawk  3.3.32.3 

Heavy  Tactical  Vehicles  3.3.32.39 

hel 1 f ire/Ground  Laser  Designators  (Hel If ire/GLD)  3.3.32.16  History  1, 

Human  Engineer  Laooratory  (HEL)  3.3.13.1 

Human  Factors  2.5.1 

Human  Factors  Engineering  5.4.1 

Incorporation  of  Pre-Planned  Product  Improvements  1.4, 3. 2 
Independent  Verification  and  Validation  (IV?<V)  5. 4. 2. 2,  7.9.2 
Infantry  School  3.3.21.6 
Informal  Testing  6.5.2 

Information  Systems  Cammsnd  (USAISC)  3.3.23 
Input/OutDut  Capacity  4.10.3 
INTEGRATION  RESPONSIBILITY  3.6 
INTEGRATION  TESTING  6.10 
Integration  Tests  5.19.3 

Intelligence  and  Security  Command  (INSCOM)  3.3.22 
Intelligence  Center  and  Scnool  3.3.21.7 
I  nt e^ccm  2 . 4 . 4 . l 


In te-*?ce5  4, 


■•’cci  *  1  ijti  one 


_aocr;tc-v  _c~ra-c  ■  '  -■...I.- 

uergtn  of  Stress  Testing  6.G.1 
Levels  Software  Testing  Required  6.' 
LI~E  CrC'^E  COSTS  7.12 


INDEX-6 


'j;\':UoS(F!ED 


AFV  CRMP 
VOLUME  XIV 


UNCLASSIFIED 


SUBJECT 


1  SEPTEMBER  87 
INDEX 


PARAGRAPH 


Li-fe  Cycle  Software  Engineering  Center  (LCSEC)  7,3.2 
Light  Armored  Vehicles  (LAV)  3.3.32.17 
Combat  Vehicles  (LCV)  3.3.32.16 
Tactical  Vehicles  3.3.32.41 
Local  Network  2. 4. 4.  3 
Logistics  Center  (LOGCEN)  3.3.5 
Ml  Abrams  Tank  System  3.3.32.44 
M113  Family  of  Vehicles  3.3.32.21 
MlAl  Abrams  Tank  3.3.32.46 
M60  Tanks  3.3.32.47 

M9  Armored  Combat  Earthmover  (ACE)  3.3.32.20 
Management  1.5.1 

Management  and  Control  Software  5.7.5 

MANAGEMENT  RESPONSIBILITIES  3.3 

MASTER  ACQUISITION  SCHEDULE  4.8 

Materiel  Sustainment  Costs  7.12.4 

Medium  Tactical  Vehicles  3.3..32.40 

Memory  Growth  Requirements  4.  10.  1 

METHODOLOGY  2. 6,5. 4. 2. 1 

Military  Police  School  3.3.21.9 

Mines,  Countermines  and  Demolitions  3.3.32.22 

Missile  and  Munition  Center  and  Scnool  3.3.21.8 

Missile  Command  (MICOM)  3.3.10 

Mission  Fighting  Station  2. 4. 4. 4 

Mobile  Electric  Power  (MEP)  3.3.32.23 

Mobile  Subscriber  Equipment  (MSE)  3.3.32.24 

Mortar  Systems  (Provisional)  3.3.32.25 

Multi -Service  Communications  Systems  (MSCS)  3.3.32.27 

Multiple  Launch  Rocket  System  (MLRS)  3.3.32.26 

Naming  Conventions  5.12.3 

NATO  Intercoe-'aci  1 1  tv  5.23.3 

NBC  '^’rotection  tor  Ccmaat  Vehicles  and  Crews  3.3.32.54  rr.  cnt  .'liicti 

Devices  3.3.32.2S 

Nuclear  Men: tiers  3.3.32.2? 

Cojectivee  1.4.C.1,  1.-1.2.4 
Operational  Environment  Testing  6.10.3 
Software  Testing  5.19.5 
Test  Evaluation  (0TS<E)  6.17.2.2 
Test  and  Evaluation  Agency  (OTEA)  3.3.15,  6. 2. 2. 6 
TESTING  (OT)  6.12 

Operations  Tactical  Data  Systems  (OPTADS)  3.3.32.30  Ordnance  Center  and 

School  3.3.21.10 

Organization  6.2.1 

Organization  of  the  CRMP  1.8.3 

OT&E  Personnel  Requirements  6.17.3.2 

Other  Personnel  7.7.2 

Patriot  3.3.32.4 


INDEX-7 


Ul’iClAilSIFIED 


AFV  CRMP 
VOLUME  XIV 


UNCLASSIFitO 


1  SEPTEMBER  87 
INDEX 


SUBJECT 

Personnel  6.17.3 
Personnel  Costs  7.12.5 

REQUIREMENTS  7.7 
RESOURCES  3.2 

Physical  Con-f iguration  Audit  <PCA)  7. 6. 4. 2 
PHYSICAL  RESOURCES  5.20 
PLAN  FOR  SUPPORT  CHAPTER  7 

Plans  To  Establish  Support  Facilities  7. 1.1.1 

PLRS/TIDS  3.3.32.31 

PM  and  PEQ  Organizations  5.2.6 

PM  Army  Command  and  Control  Systems  (PM  ACCS)  3.3.33.3 

PM  Combat  Identi -f i cati on  Sv  =  tems  (PM  CIS)  3.3.33.2 

PM  Joint  Tactical  Fusion  (PM  JTF)  3.3.33.1 

PM  or  PO  Organi zati ons  3.3.32 

Position  Navigation  2. 4. 4. 5 

Post  Deployment  Support  4.12.5,  7.2.6 

Preliminary  Design  5. 4. 2. 3 

PREPARATION  OF  TEST  DESCRIPTIONS  6.7 

Processing  Capacity  4.10.2 

Production  Costs  7.12.2 

Decision  1.4. 3. 3 

Production/Deployment  (P/D)  1.6.2,  2.6.3 
Program  Executive  O-f-ficer  (PEO)  4.2. 1.5,  6.2.10,  7.3.5 
Management  Control  System  (PMCS)  5.3.3 
Management  Support  4.2. 1.1 
Managers  4. 2. 1 . 6 
STRUCTURE  1.5 
SUMMARY  1.4 

Programmer  Unit  Testing  6. 5. 7. 2 
Progi-amming  6. 5.  7,1 
=Tog'^ammi ng  ano  Unit  Testing  6.5.7 
Prog''am(ri no  Lang'.iages  l.'.T 
“■‘-eject  Engineer  '.“E/  7.1’.! 

^'-cject  ranagenent  Gttice  '-MQ)  7.3.1 
-reject  "ilestcne  Crarts  t.t.l 

Proof  ct  “‘'incipie  Pnase  (Fy5S-E9'  1.4, 2.  2.2.1. 

PURPOSE  1.2 

QUALITY  ASSURANCE  5,4 

Quality  Assurance  Flan  5.4.4 

Quality  Assurance  Practices  5.21.1 

Quartermaster  School  3.3.21.11 

Reconnai sance.  Surveillance,  Target  Acquisition  (RSTA) , 
Related  Programs  1.4. 2. 3 
Requirements  Allocation  4.4.1 
Requirements  Analysis  5. 4. 2. 2 


INDEX. 8 

INDEX-8 


PARAGRAPH 


AFV  CRMP 
VOLUME  XIV 


1  SEPTEMBER  87 
INDEX 


Requirements  De-finition  3.9.1 
Requirements  Traceability  5.3.1 
Responsibilities  6.2.2 
Review  and  Audits  5.3.2 

Rights  to  Computer  and  Communication  Resources  So-ftware  4. 1.1.6 
Satellite  Communications  3.3.32.32 

Saudi  Arabian  National  Guard  (SANG)  Modernisation  Program  3.3.32.33 
SAVA  Management  Steering  Committee  3.3.31.2 
SCOPE  1.8 

SECURITY  REQUIREMENTS  AND  CONTROLS  5.22 
Signal  Center  3.3.21.12 

SIMULATION  TECHNIQUES  AND  REQUIREMENTS  5.24- 
Simulations  and  Mock-ups  1.4. 2. 2 

Single  Channel  Ground  and  Airborne  Radio  Subsystem  3.3.32.34 
SIZING,  TIMING  AND  PERFORMANCE  MANAGEMENT  5.9 
Smoke/Obscurants  3.3.32.35 
So-ftware  Acquisition  4.5.1 
Analysis  5.7.2 
Classi-f  ication  1.9.2 
Configuration  Management  5.13.2 
Deficiency  Management  5.3.1 
DEFICIENCY  PROCEDURES  6.16 
Design  1.9.4 

Design  Methodology  5.4.2 
DESIGN  PLAN  5. 16 
Design  Specification  5.12.6 
DEVELOPMENT  APPROACH  5.14 
Documentation  5.12.4 
IMPLEMENTATION  PLAN  5. 17 
INTEGRATION  5.18 
Integration  and  Testing  6.10.1 
Maintenance  7.2.7 
Performance  Evaluator  6.17.1.3 
Producti on  5.19.6 
Quality  5. 4. 4. 1 

REQUIREMENTS  DEFINITION  PLAN  5.15 
Requirements  Specification  (SRS)  5.12.5 
STRESS  TESTING  6.6 
Support  Facilities  3.7.1 
TESTING  AND  EVALUATION  PLAN  5.19 
TESTING  METHODOLOGY  6.5 
Soldier  Support  Center  (SSC)  3.3.6 
Special  Mission  Support  Module  2.4.4.15 
Special  Tools  6.17.1 

Specification  Deficiency  Management  5.8.2 
SPECIFICATION  TESTING  6.3 
STAFFING  REQUIREMENTS  3.5 

Standard  C'^ew  Interface  Specifications  2.5.3 
STANDARD  I Z.  I'lON  AND  COMMONALITY  4.6 


AFV  CRMP 
VOLUME  XIV 


uhclassified 


1  SEPTEMBER  87 
INDEX 


SUBJECT 


PARAGRAPH 


STANDARDIZATION  AND  PROVEN  APPROACH  3.8 
Standards  and  Conventions  5.21.2 
Status  Accounting  5.10.3 
Status  and  Cost  Reporting  5. 3.2.2 
STATUS  REPORTING  AND  MONITORING  5.6 
Status  Reports  5.6.2 

Steps  in  So-ftware  Recon-f i gurati on  7.2.4 
Stinger  3.3.32.5 

Stress  Testing  ai  Continuously  Operated  Systems  6.6. 
Stress  Testing  oP  Periodically  Operated  Systems  6.6. 
Subcontract  Management.  4. 1.1.7 
Subprogram  Tests  5.19.2 
Subsystem  Documentation  7.4.2 
SUMMARY,  ACQUISITION  MANAGEMENT  4.15 
DEVELOPMENT  MANAGEMENT  5.25 
GENERAL  1.13 
PLAN  FOR  SUPPORT  7.15 
PROGRAM  MANAGEMENT  3.12 
REQUIREMENTS  ANALYSIS  2.7 
TEST  AND  EVALUATION  6.19 
Support  Be-fore  Deployment  7.2.2 
During  Testing  7.2.3 
EQUIPMENT  3.10 
FACILITIES  4.12 
ORGANIZATION  7.2 

ORGANIZATION  RESPONSIBILITIES  7.3 
PHILOSOPHY  7.1.1 
So-ftware  5.7.,4_ 

So-ftware  Deliverables.  4.  1.1.5 
3U='PGRTABILITY  DEMONSTRATION  6.14 
Supccrting  Commancs  3.2.2 
r'/sCen  Dociji-nent at  1  on  7.4.1 


^■e^*a''(7.ance 
REQUIREMENTS  1.9 

SYSTEMS  ENGINEERING  APPROACH  4,4 
TAC  INTEL/EW  System  (Provisional)  3.3.32.37 
Tactical  Airborne  Remotely  Piloted  Vehicle/Drone  Sys 
Command  and  Control  2.3.1 
Information  and  Feedback  2.3.2 
Vehicles  3.3.32.38 
Tailoring.  4. 1 . 1 . 3 

Tank  and  Automotive  Command  (TACOM)  3.3.S,  6. 2. 2. 7 
Tank  Main  Armament  Systems  (TMAS)  3.3.32.45 
Tank.  Systems  3.3.32.43 


INDEX-10 


' 


AFV  CRMP' 
VOLUME  XIV 


j  i  <ur{  oc  ’  r;  ro 

u  i  iO»>i  1  ‘  L.  I  ^ 


1  SEPTEMBER  07 
INDEX 


SUBJECT  PARAGRAPH 

Target  Processor  5.20.2 
TECHNICAL  AND  MANAGEMENT  CONTROLS  5.3 
TECHNOLOGY  ASSESSMENT  7.14 
TEMP  and  CRMP  Evaluation  6.1.4 

Test  and  Evaluation  3.9.4 

Test  and  Evaluation  Command  (TECOM)  3.3.14 

Test  and  Evaluation  Master  Plan  6.1.3 

Test  Integration  Working  Group  (TIWG)  b. 2.2.2 
ORGANIZATION  AND  RESPONSIBILITIES  6.2 
Planning  6.5.5 
Plans  6.5.4 
Requirements  5.19.1 
Requirements  Analysis  6.5.3 
SCHEDULES  6.18 
SUPPORT  REQUIREMENTS  6.17 

Test,  Measurement  and  Diagnostic  Equipment  (TMDE)  3.3.32.43 
TESTING  7.9 
Testing  Goal  6.1.1 

Policy  6.1.2,  7.9. 1 
Requirements  6.5.2 
The  Collection  Process  7.11.5 
The  Installation  Process  7.11.4 
The  Replication  Process  7.11.2 
The  Shipment  Process  7.11.3 
Topographic  Support  Systems  3.3.32.49 
TOW  3.3.32.50 
Traceability  5.12.2 
TRADOC  Analysis  Command  (TRAC)  3.3.19 

Combined  Arms  Test  Activity  (TCATA)  3.3.20 
Service  Schools  3.3.21 

Training  and  Doctrine  Command  (TPADCC)  3.3.2,  4.2. 1.4,  5.2.5.  ; 

7  “T  T 

T'-aining  Devices  iTFADE;  7.3.32.51 
REQUIREMENTS  '.E 
■TRANSFER  AND  TURNOVER  4.: 4 

TRANSFER  OF  PROGRAM  MANAGEMENT  'ESPONSIBILITY  7. lO 
Transportation  School  3.3.21.13 
Troop  Support  Command  (TRQSCOM)  3.3.11 
U.S  Army  Health  Services  Command  (H5C)  3.3.25 
U.S  Army  Materiel  Systems  Analysis  Activity  (AMSAA)  3.3.18 
Unit  Level  Testing  6. 5. 7. 3 

US  Army  Combined  Arms  Combat  Development  Activity  (CAC  3.3.4. 1 
Development  and  Employment  Agency  (ADEA)  3.3.17 
Electronic  Technology  Devices  Lab  (ETDL)  3.3.13.3 
Engineering  Topographic  Labs  (ETL)  3.3.24 

INDEX. 11 

INDEX-11 


1  1  {  i  5  i  V  N  I  i  W*  4  * 


AFV  CRMP 
VOLUME  XIV 


LINCLASSiFiED 


1  SEPTEMBER  87 
INDEX 


SUBJECT 


PARAGRAPH 


US  Army  Logistics  Evaluation  Agency  (USALEA)  3.3.16 
Research  Institute  (ARI)  3.3.28 
Research  O-f-fice  (ARQ)  3.3.27 
US  Navy  and  Air  Force  C3  Interoperability  5.22.2 
User  Training  7.8.2 
VCOS  Communications  2.4.4 
Firmware  2.4.3 
Hardware  2.4.2 
So-f tware  2.4.1 
Vehicle  De-fense  2. 4. 4. 7 
Vehicle  Interchangeability  5.23.4 
Voice  Communication  2,4.4.10 


INDEX-12 


jr'ivLA^SiFiED 


UNCLASSIFIED 


-Gl3  ~l''5t 


Department  ot  tne  Army 


G"FICIA:_  SUSIfjESS 
Penalty  tor  private  u- 


Director 

AFV  last:  Force 

A'T'i;  DA«0-AFV-!1 

'GDI  Division' 


S®ci-r.d  "&M  T‘?30 


INDEX-14 


UNCLASSIFIED 


^S5S5!5©SWW5 


\L.  tJ  a 


INDEX-16 


